[gclist] Destructor FAQ, post-mortem finalization

[David Ungar]

Back when I was consulting at ParcPlace on the
garbage collector, Frank Jackson, Alan Schiffman, Peter Deutsch & I
worried about getting clean semantics for finalization.
We eventually came up with the post-mortem scheme that Mario
outlined below, and the PPSers went and obtained a patent on it!
(So without doing the odious part of the work, I found myself
 part-holder of a patent.)

As Mario said, the key idea was to avoid all the complications
dead objects returning to life by requiring the application
to keep any state needed for finalization somwhere else.
I like its simplicity.
While other schemes may look ok w.r.t. particular examples,
it can be hard to convince yourself that the killer example
is not lurking out there.



At 11:25 AM 3/7/96, Mario Wolczko wrote:
>Nobody has mentioned post-mortem finalization in any detail, so I'll
>throw in a paragraph or two...
>
>David Gadbois's contribution on destructors mentioned possible problems
>when GC systems also incorporate finalization.  Post-mortem
>finalization attempts to solve these problems.
>
>I believe it was invented by Frank Jackson and Dave Ungar for
>ParcPlace Smalltalk (I'm not absolutely certain of this, but I can
>check with Dave Ungar next week).  In PPS is it used in conjunction
>with weak pointers.  All weak pointers are contained within instances
>of a special class, WeakArray.  When an object is reclaimed and has
>weak references, the garbage collector nils out the weak references.
>This solves one problem: because the object really is reclaimed, there
>is no chance that finalization code can revive it.  When it's gone,
>it's gone.  However, we still need some way to actually perform
>finalization.
>
>In addition to nilling out weak pointers, the collector makes
>available to the mutator the identity of each weak array containing
>references that it nilled out, and the indexes into that array of such
>references.  It is then up to the mutator to figure out from this
>information what finalization actions are required.  Typically, the
>mutator maintains for each weak array another array of non-weak
>pointers to copies of the objects referenced from the weak array.  The
>copies contain the essential state required for finalization (such as
>file descriptors and window handles that need to be closed).  Once the
>mutator has been informed by the collector which elements of the weak
>array have been nilled, it can then use the information in the copy to
>perform finalization actions, and then nil out the strong pointer to
>the copy.  The copy is typically only referenced from this array, so
>that causes it to become garbage and be reclaimed.
>
>So, the key ideas of this scheme are that objects referenced only by
>weak pointers are reclaimed anyway, the weak pointers are nilled by
>the collector, and the mutator can find out which weak pointers have
>just been nilled, in order to perform finalization.
>
>The only published description of this technique that I'm aware of is
>in the ParcPlace Smalltalk manuals.
>
>-Mario

-- Dave