Re: Garbage Collection in Ada

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Lars said

"With GC the problem of "clean up" of memory is defined away. There is no
way to be "sloppy" about deallocating memory with GC. There is no
problem, pure and simple. That this is hard to accept is IMHO a clear
indication that this really is a hard problem (without GC). We are so
afraid of memory leaks that we find it very hard to accept an automatic
solution. Note: this doesn't mean that GC solves every conceivable
memory related problem, but knowing when to release memory is solved so
the result is not "slop to clean up"."


Hmmm! I am surprised anyone would write this if they had used GC languages.
The problem of cleanup is not define away at all, and indeed, in some
respects can be trickier, because you don't think about it up front as you
have to in a system where you use finalization for freeing things, or even
more manual techniques.

The problem is that it is all too easy to have a global variable around
that accidentally holds on to a giant structure. Or for example, depending
on your implementation, taking the 'Access of one field of one record in
some big structure may end up holding on to an entire subgraph that you
do not need.

You may in practice need to be just as careful about adding

   Junk := null;

statements to your program as you are now about adding

   Free (Junk);

statements to your program now. 

GC is certainly a magic bullet solution to the problem of accidentally
freeing storage that should not be freed, but it is NOT a magic bullet
with respect to not freeing things that should be freed. People who 
approach a GC language environment with this expectation will be
disappointed!