[gclist] Destructor functions and GC (contains new, I think, idea)

[David Petrie Stoutamire]

> Finalizers are also a poor way of dealing with things that must be
> done. In a conservative collector they may not be done.

This isn't true.  Nothing prevents an implementation from dealing with
finalization in an extra step before termination, in the same way that
unix `atexit' works.  

Unless the mutator is invoking garbage collection manually and the
language defines exactly what it means to be garbage and exactly when
objects qualify (rare), conservative collectors don't have any weaker
guarantees about finalization timing than precise collectors.  For
example, collection may never occur for any program that doesn't run
out of initial heap space, precise pointers or no.

Another misconception I've heard is "oh no, you can't _require_
finalization before termination because that means you'd have to
garbage collect before terminating."  Given the lack of guarantees
about when finalization occurs, finalization doesn't _have_ to be
associated with collection at all, for example, just treat objects to
be finalized as roots and do all finalization at termination, making
finalization registry just a glorified `atexit'.  (I'm not saying this
is a great idea, just pointing out how weak the semantics actually are
once you eliminate the ordering problem.  I realize the whole point of
finalizing at collection time is to free resources as soon as
possible.)

The only real-world example I've seen on the list so far where order of
finalization matters (other than because of destructors in legacy code)
is the example of multiple buffers attached to a single file handle,
where the buffers must be flushed before the file is closed.  This
doesn't strike me as problematic; it's easy for the mutator to deal
with by sharing a single buffer or by registering the buffers with the
handle object, not requiring special GC ordering guarantees.  Are there
other examples?

I guess I'm taking the stance that it is possible to obviate the issue
by proper language design, and that the great hairiness associated with
the semantics of finalization is really an just artifact of trying to
incorporate finalization into legacy systems not designed for it.  Any
disagreements?

    - Dave

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