[gclist] Ephemerons [Was Re: Finalization and death notices]

[Eliot Miranda]

"Kerns, Bob" wrote:
> 
> The drawback to all this, compared to death notices, is that presence on the
> queue extends the object's lifetime.

Read
           Ephemerons: a new finalization mechanism; Barry
           Hayes; Proceedings of the 1997 ACM SIGPLAN
           conference on Object-oriented programming
           systems, languages and applications, 1997, Pages
           176 - 183 

An ephemeron is a reference to some object that the garbage collector
does not traverse unless there exist references to the object from
non-ephemerons.  At the end of a gc cycle (scavenge, incremental gc,
total gc, etc) the set of ephemerons that are the only references to
objects are queued for finalization.  At this point the gc does traverse
the references, preventing the objects referred-to by ephemerons from
being traversed.  So ephemerons are a way of partitioning the object
graph into a "referenced from roots" subgraph and a set of "referenced
only from one or more ephemerons" subgraphs.

In this way ephemerons solve the various problems to do with extending
object lifetime such as attaching property lists to objects, problems to
do with having references between sub-graphs that need independent
finalization and so on.  In our Smalltalk system ephemerons are
effectively subclasses of Key, the class of an association in a
dictionary.

> 
> A buggy mutator that forgot to close the file stream not only leaves open
> the file descriptor -- it also leaves allocated the buffer storage, index
> B-Tree, pool of connection objects, and other things associated with the
> file.
> 
> I know, I padded this list beyond a bare buffered file stream; the point is,
> this is an unbounded amount of storage to hang onto, just to enable a final
> cleanup on the file descriptor!
> 
> I like true death noticies, instead of these "near death notices", because
> they focus on the real requirements.
> 
> -----Original Message-----
> From: Nick Barnes [mailto:Nick.Barnes@pobox.com]
> Sent: Monday, October 08, 2001 4:27 AM
> To: gclist@iecc.com
> Subject: Re: [gclist] Finalization and death notices
> 
> All this talk about finalization prompts me to describe the
> finalization system we have in our Memory Pool System (MPS).  Here it
> is:
> 
>   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.
> 
> Notes:
> 
> (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
> mutator.
> 
> (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

-- 
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd