[gclist] Finalization order is easy.

[Charles Fiterman]

>It is undecidable only in systems allowing the computation (forgery) of
>object pointers.  In languages like Java, Smalltalk, Self etc where one
>can only construct a valid pointer by instantiation, and where there is
>no computation on object pointers then it is impossible to forge or
>otherwise disguise pointers.  In this context it is a decidable problem
>(a scan followed by a trace will divide objects into reachable and
>unreachable ones).  However, latency and ordering of the running of
>finalizers is a harder problem.

These become simple with a key AH-HA. Finalizer order is in the semantics
of the mutator and is either trivial or trivially impossible.

Suppose you have a list of objects with finalizers which output data on
a report. The order of the finalizers is determined by the desired order
of the report, mutator semantics. There is nothing the collector could
ever do to determine it. The mutator can assign a finalizer order number
to every finalizer. This is either trivial or trivially impossible and in
either case that's the mutator's problem.

Consider the common case where a buffer's finalizer dumps its contents
to a file and the file's finalizer closes it. Since the file's finalizer
require's no pre-finalized objects it can be MAX_INT. The buffer's order
can be anything less. But even in this case order is in the semantics
of the mutator, an exception for writing to a closed file object could
be the desired semantics.

Having a finalizer order blows away latency problems, you just sort the
finalizers.
			-  
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.