[gclist] Guardians

[Hans Boehm]

> We
> concluded, as many people on list list probably have by now, that
> there is no way to automatically determine the order in which
> finalization should occur because there are cases when the order is
> program dependent rather than topologically dependent (assuming
> finalization actions are not severely restricted, e.g., freeing
> storage for an object in its destroy method in C++).

Some of us isn't convinced of this.  Could you give an example in which you
don't want topological ordering, possibly after discarding some pointers
irrelevant to finalization?

> ... Since finalizer code is never executed as part of a collection, no
> critical sections are necessary.  Using the OS analogy, an interrupt
> simply queues up an event that is handled by a daemon process outside
> of the context of an interrupt.

This is also the approach that was used in Cedar.  (See Paul Rovner, "On
Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically-
-Checked, Concurrent Language, Xerox PARC CSL-94-7, July 1985.)  I agree that
it's the right approach in a single-threaded environment.  In a multi-threaded
environment, finalizers need to obey the normal conventions in any case.  So
typically yopu just want to run them in their own thread, asynchronously.  That
can of course be done with your interface.

Hans

-- 
Hans-Juergen Boehm
boehm@mti.sgi.com