Re: Garbage Collection in Ada

[ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>The problem is that it is all too easy to have a global variable around
>that accidentally holds on to a giant structure.

It is also easy to do this with manual allocation.
The practical issue that _I_ see here is that garbage collection
enables "storage profiling" where you can _ask_ "what storage is
being held onto and why?".  There was a very nice paper about a
garbage profiling published in PLDI 96 (I _think_ that was the conference).
Garbage profiling is a valuable development tool, just like time profiling,
and I hope it is soon adopted in many systems.

In a system which achieves economies (if such economies exist) by not
doing garbage collection, it is much harder to provide such facilities.
You can indeed ask where the currently retained blocks were _allocated_
(or at least you can in the memory debugging library I use for C), but
you can't ask "_why_ is this block retained?"

So the bottom line is that when you consider the whole lifecycle instead
of just a single run, garbage collection PLUS garbage profiling is a better
bet than relying on the programmer to be perfect.

>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.

And again, in a manually managed system, exactly the same situation can
arise, and the programmer may not dare to free the storage manually because
the analysis to prove it safe statically is too hard (or in the case of
someone else's code receiving the 'Access), impossible.

And again, garbage profiling can help with this, whereas no-support-for-gc
means in practice no support for garbage profiling either.

>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. 

This seems unlikely, because the former is a *local* decision, that
*this* reference is no longer needed, while the latter is a *global*
decision, that *all* references are no longer needed.

I would very much like to see LCLint-style memory checking in a tool
for Ada.

>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.

But it *is* half of the magic bullet.  The other half is garbage
profiling, which requires at least the same hooks as garbage collection.
If you are concerned about the memory use of your program, you want to
know
 - which objects are being retained after their last real use
 - and which references are keeping the dead blocks around
It _is_ possible to build a development tool for manual management
that tells you which objects are being retained after their last real
use (trace allocation, deallocation, loads, and stores, then inspect
the trace).  But the other half you need is _why_ the objects are
being retained after their last use.

>People who 
>approach a GC language environment with this expectation will be
>disappointed!

This is not an argument *against* automatic garbage collection,
it is an argument *for* garbage profiling.
-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.