[gclist] RE: Destructor functions and GC

[David Petrie Stoutamire]

> Thomas Weitzel wrote to us on March 7:
> Perhaps finalizers on all live objects should be called when the
> program exits, so that we _can_ rely on finalizers to be called at
> some point.
> 
> I think finalizers are the right way to deal with these resources.
> Essentially the finalizer has to be something that MUST be done at
> SOME time, but there is no guarantee on WHEN it will be done.  If the
> finalizer does something that depends on when it is done, then it is
> the programmer's fault for making that assumption.

These are the choices I made for specification of how finalization
works in Sather.  There are no guarantees about when finalization runs
other than it will happen exactly once before the program terminates.
In the parallel/distributed extension this means that finalization
routines may also be concurrent.  However, deallocation doesn't happen
until all finalized objects that can reach an object have run their
finalization; objects to be finalized are considered roots of a sort
with respect to actually deallocating.  That way there can't be
dangling pointers in finalization code.

In systems without explicit destructors and conservative deallocation,
is order of finalization an issue at all?  I've only needed them for
freeing external resources.  Finalizing whole clumps of data as a unit
doesn't seem tricky at all - just pick a representative object and have
that perform the group's finalization.  I'd be very interested in
hearing experiences to the contrary.

(BTW, this is with respect to my own collector - we still ship with the
Boehm collector because it is so darn portable.)

    - Dave

--
David Stoutamire
http://www.icsi.berkeley.edu/~davids