Re: Garbage Collector [Was: C bug of the day]

["Robert I. Eachus" <rieachus@attbi.com>]

Robert A Duff wrote:

> Also, in order to tell which objects in a given storage pool are
> garbage, you have to know about all the pointers into that pool from
> outside -- from other pools, from the stack, and from statically
> allocated memory.  The storage pool doesn't help there.
> 
> Unless you're talking about so-called "conservative" garbage collection,
> in which case you can use existing ones (see Boehm).
> 
> In general, a good garbage collector requires cooperation from the
> compiler.  Even a so-called "conservative" GC requires that the compiler
> avoid certain "tricky" optimizations.

There are two issues here.   First, if you want to build a "full" 
garbage collector, it needs to be compiler specific.  Martin proposed a 
GNAT specific GC, so that is covered.  Yes, new compiler versions might 
require updating the GC package.  So it would be a good idea to 
contribute the package, and get it distributed with the GNAT compiler.

The argument about "knowing" where the pointers are is to me, 
irrelevant.  As far as I am concerned, a garbarge collection package for 
any compiler would require the compiler recognize that the storage pool 
required a special type of pointer.  (Assume for the moment that their 
is a compiler specific pragma to use these special pointers, and of 
course the pragma argument is the storage pool, and it should be in the 
package that creates the storage pool type.)

So the work required to implement a garbage collecter breaks into two 
parts (well three) parts:  Decide what kind of special pointer is 
required.  If I were doing it, I'd make the pointer, excuse me, access 
type class be a controlled type, and have the finalization operations 
keep a list of all the current pointer locations.  Second, modify GNAT 
to support the special pointer type, and third implement the garbage 
collector.

As I see it, the advantage of using a controlled access type would be 
that all the grody stuff could be "hidden" there, and the actual values 
would not need to be any larger than standard pointers.  (But every copy 
of a pointer would create a new entry in the management table, when the 
table fills up--or the storage pool--garbage collection gets triggered.)