[gclist] gc interface

[boehm.PARC@xerox.com]

Re: terminology

I'm quite willing to settle on synchronous vs. asynchronous cleanup routines if
that terminology is less contentious.  (Out of curiosity, I would still like to
see a pre-86 published reference to "finalization" in the synchronous sense.)

My claim is still that asynchronous cleanup routines are used for reclaiming
nonmemory resources.  But this may require arbitrary computation.  These
resources are sometimes invented by the user, so they have to part of the user
code, not part of the collector implementation.


Hugh Redelmeier wrote:

  "+ perhaps this suggests that if the finalizer wishes to
    re-vivify an otherwise inaccessible object that its object
    refers to (cf. the cycle discussion), it should have the
    right and obligation to "mark" it.

  + if the GC is not allowed to create new stuff on the heap
    during a collection (so that GC cannot fail due memory
    being full when it was invoked), then perhaps finalizers
    ought not to be allowed to create new stuff on the heap.
    More generally, perhaps the restrictions on what a GC can
    do might apply to the finalizer.  The justification is that
    while most of the program code is built "on top of" the
    garbage collection abstraction, finalizer code is part of the
    implementation of that abstraction."


I'm not sure restrictions on such cleanup routines like the ones you proposed
buy you anything.  Conventionally, clean up routines are not invoked during a
garbage collection; the collector builds a queue of cleanup routines waiting to
be inoked, and the user-supplied routines are run when the GC finishes.
Objects accessible from these routines are not reclaimed until the next GC
cycle. This means that allocation is not a problem.  More importantly, cleanup
routines may acquire locks, something which is often necessary, but not
possible during a GC if the collector stops other threads.  This is also safe,
in the sense that bad client code cannot lead to dangling pointers.  It is
orthogonal to the contentious issue of order of invocation of the cleanup
procedures.

Hans-J. Boehm
Standard disclaimer ...