[gclist] Finalization and death notices

Nick Barnes Nick.Barnes@pobox.com
Mon, 08 Oct 2001 12:26:43 +0100

All this talk about finalization prompts me to describe the
finalization system we have in our Memory Pool System (MPS).  Here it

  The mutator may register an object for finalization.  It may
  register the same object for finalization more than once (as if
  incrementing a counter).
  When the MPS observes that an object registered for finalization
  would otherwise be reclaimable, it deregisters it for finalization
  (as if decrementing the counter) and adds a finalization message,
  containing a reference to the object, to its message queue.
  The message queue may be read by the mutator, at the mutator's
  convenience.  Messages must be explicitly destroyed by the mutator.


(1) The object remains alive until (at least) such time as the mutator
destroys the finalization message.  The mutator is free to do what it
likes with the object, including create new references to it and
re-registering it for finalization.

(2) Finalizers (if any) get run by the mutator, synchronously with the
mutator's other activity, at the mutator's convenience.  They are not
run by the MPS.  Any problems with locking, threads, and object
ownership are up to the mutator to resolve (as usual).  It is simple
for the mutator to run finalizers by module (by adding another queue,
with filtering by module, on the mutator side).

(3) Finalization ends when a finalization message is enqueued.  As far
as the MPS is concerned, any "finalizer" is just another part of the

(4) Ensuring that finalizers are run eventually is a problem for the
mutator.  If the mutator doesn't read the queue, or doesn't run the
finalizers, or takes an early bath with messages still on the queue,
that is the mutator's problem.

We don't use liveness terminology in this context, because the object
in question is certainly _not_ dead.  How can it be dead when I have a
pointer to it right here?  Talk about liveness in the context of
finalization leads to all sort of semantic nonsense like "resurrection
of the dead".  The mutator has simply asked the GC to do it a favour
by using the GC's uniquely global knowledge of object reachability to
let it know when an object is not _otherwise_ reachable.

Nick Barnes
Ravenbrook Limited