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

[Charles Fiterman]

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

The problem with this is finalization dependencies.

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

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

I have just had a lightning bolt inspiration. Suppose we have a special
finalizer called a must-finalize. If a must-finalize object is refered
to in another object's finalizer code thats a bug. You get the error
right there when you aim the pointer. At end of job the must-finalize
objects are all finalized.

There must be a way to loosen that restriction. Imagine an execution
frame with a must-finalize marking. At end it returns to another
execution frame which may have a must-finalize marking.

What is the weakest restriction that allows all finalizable objects
found unused in a collection pass to be finalized in that pass? Assume
the collector can do some work sequencing them. Go down the list sorting
it so that an object appears before anything it needs. If any cycles
appear thats a bug. Now once an object is on the list its going to
die. We man need to keep pointers to such objects from being stored
outside the scope of some things.