[gclist] Guardians to finalize objects

[Charles Fiterman]

At 10:58 AM 4/4/97 -0800, you wrote:
>Isn't this basically the Java mechanism cleanly embedded into Scheme?
>
>It effectively handles finalization in a single-threaded environment by
>queueing objects need for finalization, and then running finalizers at the
>programs explicit request.  (The same technique, minus the nice Scheme
>embedding, was described in the 1985 PARC tech report by Paul Rovner.)
>
>As far as I can tell, it pushes the dependency issues back into the hands of
>the programmer.  As I've argued before, this doesn't strike me as a good idea.
> Ordering requires flobal dependency information, which the garbage collector
>has, but the programmer doesn't.

The collector has the wrong kind of dependency information. A depends on B
is very different from A's finalizer requires a pre finalized version of B.
In fact A's finalizer might require a post finalized version of B. This
doesn't make sense in C++ where destructors smash vtable pointers but it
makes sense everywhere else.

Finalizer ordering requires mutator semantics which the programmer has and
the collector doesn't. The belief that finalizer ordering can be derived
from examining ordinary pointers is merely misleading and results in problems
like not running finalizers because of pointer cycles or running finalizers
so slowly that the program ends first.

If you have a linked list of finalizer objects and the finalizers add lines
to a report, the desired finalizer order is the desired order of the report.
No examination will tell you that.

Object composition even suggests multiple finalizer ordering. That is an
object's parts may have different finalizers caught up in their own dependencies.
Again in C++ this is nonsense but outside C++ it makes perfect sense.


			-  
Charles Fiterman		Geodesic Systems
414 North Orleans Suite 410	Phone 312 832 1221 x223
Chicago IL 60610-4418		FAX   312 832 1230
				http://www.geodesic.com

A computer language without garbage collection
  is like a city without garbage collection.