SGCL - Garbage Collector for C++

[Richard Herring]

It's true. If you do not have the skills and the know-how to keep track
of your own objects, and manage their lifetime,

.... or if you think garbage collection is about lifetime management ...

 

[James Kanze]

And you'll be even more professionally irresponsible if you
use a so-called "labor saving device" as merely a crutch to
support your own lack of experience and know-how, rather than
taking the time, learning, and educating yourself on how to do
it right in the first place, instead of relying on
mis-designed spaghetti code to pull you nuts out of the fire.

Doing it right is doing it in the most effective and
maintainable way possible. Not inventing a lot of make-work
just to be able to bill extra time.

 

[James Kanze]

In message <[email protected]>,

... or if you think garbage collection is about lifetime
management ...

Agreed. If you don't understand your tool, you won't be able to
use it correctly. And garbage collection has nothing to do with
lifetime management; it only intervenes in memory management.
(It's also useful for catching dangling pointers. If the object
is dead, you can mark it dead, and be sure that that mark won't
be overwritten as long as anyone has a pointer to the object.)

Of course, a lot of objects don't need any particular handling
when you're through with them. Once your analysis has
determined those, with garbage collection, you're through with
them; without, you've still got to write the code to clean up
the memory.

 

[Alf P. Steinbach]

* James Kanze:

Given that someone had already said "stack
overflow", I'm rather surprised that Alf missed it---he doesn't
usually miss these sort of things.

I think we rely much more on simple pattern matching (and hence expectations and
previous experience) than reasoning.

Not sure if you've read David Brin's uplift trilogy, but there's this scene
where two guys cross the wilderness and one of them plants a lot of false
evidence to convince the other there's someone shadowing them. However, the
other guy doesn't even notice all this fake evidence, because it's so bad, so
fake, so atypical, that it doesn't even reach his higher cognitive functions for
consideration... It's automatically filtered out, because it doesn't make sense
even at the lowest level of external input processing.

After some time, this other guy notices something the first one didn't, namely
that apparently there /is/ someone shadowing them.


Cheers,

- Alf (reserving The Right 2 B SOTU )

 

[James Kanze]

* James Kanze:

I think we rely much more on simple pattern matching (and
hence expectations and previous experience) than reasoning.

Not sure if you've read David Brin's uplift trilogy, but
there's this scene where two guys cross the wilderness and one
of them plants a lot of false evidence to convince the other
there's someone shadowing them. However, the other guy
doesn't even notice all this fake evidence, because it's so
bad, so fake, so atypical, that it doesn't even reach his
higher cognitive functions for consideration... It's
automatically filtered out, because it doesn't make sense even
at the lowest level of external input processing.

I'm not familiar with it, but yes. Context certainly plays a
large role; we normally only see things we're looking for, and
what we look for depends to a large degree on what we expect to
find.

I'll admit that without the comment about "recursion"
immediately up-thread, I probably wouldn't have spotted it
either. However, that word triggered something in my mind, a
comment by Hans Boehm, I think, to the effect that manual memory
management can create the same pauses people complain about in
garbage collection. With a long list or a complex tree being
his example, where destruction of the root triggers *recursive*
destruction of hundreds of thousands of elements. Without
that... (In other words, I'd already had the case explained to
me by a master.)

 

[Ian Collins]

Doing it right is doing it in the most effective and
maintainable way possible. Not inventing a lot of make-work
just to be able to bill extra time.

Your problems begin when your maintenance task is to port the code to a
platform without GC support.....

 

[Ian Collins]

Of course, a lot of objects don't need any particular handling
when you're through with them. Once your analysis has
determined those, with garbage collection, you're through with
them; without, you've still got to write the code to clean up
the memory.

Until a later maintainer alters the object (or one that it includes) so
it does require particular handling when you're through with them. Then
the fun really begins.

 

[Sam]

... or if you think garbage collection is about lifetime management ...

Let me know when you figure out why, in Java, you have to throw all these
try/catch blocks around, every time you need to deal with files or sockets,
in order not to run out of available file descriptors.

So much for garbage collection.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHyJQ4x9p3GYHlUOIRAiZrAJ9aZ1U/XuftG2Pq9/s8HYsFmO948gCfWF9W
4Hoo9VpP1AmuRNHMXjHZwo8=
=PRFw
-----END PGP SIGNATURE-----

 

[James Kanze]

Your problems begin when your maintenance task is to port the
code to a platform without GC support.....

Or to a platform without C++ support... Or in my case, to a
platform without directories, or sockets, or files, or threads.
GC support is at least as widely available as threads or
sockets.

 

[James Kanze]

James Kanze wrote:

Until a later maintainer alters the object (or one that it
includes) so it does require particular handling when you're
through with them. Then the fun really begins.

How is garbage collection in any way relevant to that? Garbage
collection is concerned with memory management, not object
lifetime management. If you have to do something special when
an object's lifetime ends, then you have to do it. Garbage
collection or not. All garbage collection does is mean that you
don't have to worry about freeing the memory under the object,
and that you can implement code to catch errors in your lifetime
management---pointers to the object that are used after the
object is dead.

 

[James Kanze]

Let me know when you figure out why, in Java, you have to
throw all these try/catch blocks around, every time you need
to deal with files or sockets,

Because Java doesn't have local objects or destructors. Which
has nothing to do with garbage collection.

in order not to run out of available file descriptors.

In Java, you use try/catch blocks, and in C++, you use
destructors. Garbage collection has nothing to do with the
issue.

 

[Ian Collins]

Or to a platform without C++ support... Or in my case, to a
platform without directories, or sockets, or files, or threads.
GC support is at least as widely available as threads or
sockets.

True, but there's plenty of embedded platforms with POSIX support where
garbage collection, even if available, would be acceptable.

If a platform didn't have threads or sockets, it would an unlikely
candidate for a port of an application that used them. Even if it was
chosen, being libraries with well documented interfaces, they could be
implemented, simulated or stubbed by any competent developer. You can't
make the same claim for GC!

 

[Ian Collins]

How is garbage collection in any way relevant to that? Garbage
collection is concerned with memory management, not object
lifetime management. If you have to do something special when
an object's lifetime ends, then you have to do it. Garbage
collection or not. All garbage collection does is mean that you
don't have to worry about freeing the memory under the object,
and that you can implement code to catch errors in your lifetime
management---pointers to the object that are used after the
object is dead.

My point, which appears to have been badly made, is that it is foolhardy
to rely on GC to clean up some objects but not others.

I don't object to the use of GC, provided it is used consistently
throughout a design.

 

[Ian Collins]

True, but there's plenty of embedded platforms with POSIX support where
garbage collection, even if available, would be acceptable.

Make that "*not* acceptable!

 

[Sam]

Because Java doesn't have local objects or destructors. Which

Java most certainly has destructors. See java.lang.Object.finalize().

Java has local objects too. But that's going to be your homework assignment
for today.

has nothing to do with garbage collection.

It has everything to do with garbage collection.

In Java, you use try/catch blocks, and in C++, you use
destructors.

Whoooooooosh!!! Right over your head.

Garbage collection has nothing to do with the
issue.

You keep repeating this, but repeating something, over and over again, does
not necessarily make it true.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHyLtix9p3GYHlUOIRAiHKAJoC3KcbBxVJ1Z6oKjdv0XSVomXRAgCfVE6A
TGgHuwpFDsuAhLEXhRyepKo=
=wmp7
-----END PGP SIGNATURE-----

 

[Sam]

How is garbage collection in any way relevant to that? Garbage
collection is concerned with memory management, not object
lifetime management.

You're making no sense.

If you separate the object destruction phase from the memory release phase,
then you must be asserting that you are going to be explicitly invoking the
object destruction phase, at some point, yourself, instead of relying on the
garbage collector on doing that.

But if that's what you're going to do, if you are going to be destroying
your objects yourself, then what exactly are you going to gain by not
freeing the memory, right then and there, instead of leaving it to the
garbage collector to free the memory at some later, indeterminate point?

If you have to do something special when
an object's lifetime ends, then you have to do it.

Bravo! You finally got it. If you're going to explicitly destroy the object,
then you're going to free the memory right than and there. To stop short
before doing that, and leaving it to the garbage collector, is absolutely
demented, and you gain absolutely nothing from doing that.

Garbage
collection or not.

If you're going to use a garbage collection model, it logically follows that
you're postponing object destruction/finalization until then. Because if
you're not -- if you're going to destroy and finalize the object yourself --
then you'll simply free the memory at the same time too, because by the
virtue of invoking the destructor, you are stating that no references to the
object remain, so you can free the memory right than and there.

Refusing to do that, and instead choosing to foist a completely unnecessary
garbage collection framework on your neck, in that situation, is completely
and utterly retarded.

And that's precisely why I wrote, right from the start, that garbage
collection is only for those who are too stupid to manage and keep track of
their objects, and their lifetime, themselves. Because if they do have
enough wits to keep track of their objects' lifetime, and invoke their
destructors at the appropriate time, they'll just release the memory at the
same time. We even have an operator for doing that. It's called "delete".

Who'da thunk it?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHyL3zx9p3GYHlUOIRAkk6AJ9KPvRDqzk5TPfuzXAHaolhHQZHygCdHja1
msGy9juqSz7xMa0VE9rLyUY=
=n8H7
-----END PGP SIGNATURE-----

 

[Alf P. Steinbach]

* Sam:

If you separate the object destruction phase from the memory release
phase, then you must be asserting that you are going to be explicitly
invoking the object destruction phase, at some point, yourself, instead
of relying on the garbage collector on doing that.

But if that's what you're going to do, if you are going to be destroying
your objects yourself, then what exactly are you going to gain by not
freeing the memory, right then and there, instead of leaving it to the
garbage collector to free the memory at some later, indeterminate point?

Mostly that this processing can be done at otherwise idle moments, or spread
over time instead of all at once (like when deleting some dynamic data structure).

It is of course not a free lunch.


Cheers, & hth.,

- Alf

 

[Ian Collins]

Java most certainly has destructors. See java.lang.Object.finalize().

But that's not an automatic destructor in the C++ sense, is it?

 

[Sam]

But that's not an automatic destructor in the C++ sense, is it?

It is a destructor in the C++ sense as in "gets invoked before the object's
memory is released".

That's precisely the point I am making. Garbage collection's only benefit is
to clean up your objects when you can't keep track of their lifetime, and
must rely on the garbage collector to destroy the objects when they no
longer have any strong references. Because if you do have the discipline to
keep track of your objects, and destroy them when they're no longer needed,
you don't need any fscking garbage collector.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHyNPKx9p3GYHlUOIRAunEAJwMc6Pxo/9NJ2Z0MNbhEbTAcbRrhACfW/B5
kdEi/tRJSOkWIHk0gIhJtxo=
=yFza
-----END PGP SIGNATURE-----

 

[Sam]

* Sam:

Mostly that this processing can be done at otherwise idle moments, or spread
over time instead of all at once (like when deleting some dynamic data structure).

And when your app does not have any idle moments, you end up running out of
memory.

<Splorf>

That actually happened at day job, last week. A tick data app ran out of
memory and crashed, because it kept chewing on the exchange's tick feed, and
had no spare cycles for the Java VM to run the garbage collector, and
release memory held my objects that were no longer in use.

Lots of fun that was.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHyNSBx9p3GYHlUOIRApFIAJ9p3LQZYu4a5WPSzAMQz6EyDariRwCeNklI
CQCSsoGtzAOTiqDqoAX0Ltg=
=ehRc
-----END PGP SIGNATURE-----