Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!swrinde!sdd.hp.com!news.cs.indiana.edu!bruggema@cs.indiana.edu
From: "Carl Bruggeman" <bruggema@cs.indiana.edu>
Subject: Re: Finalization
Message-ID: <1994Oct4.131350.2449@news.cs.indiana.edu>
Organization: Computer Science, Indiana University
References: <36erq3$c67@cantaloupe.srv.cs.cmu.edu> <36i2of$hsn@network.ucsd.edu>
Date: Tue, 4 Oct 1994 13:13:47 -0500
Lines: 71

In article <36i2of$hsn@network.ucsd.edu>,
Matt Kennel <mbk@inls1.ucsd.edu> wrote:
>Rob MacLachlan (ram+@cs.cmu.edu) wrote:
>: If resurrection is allowed, this can complicate GC, and also opens the
>: possibility that an object can be finalized more than once.  If resurrection
>: is not allowed, then there is potential for dangling object references.
>
>How about this scheme....I proposed it in the eiffel newsgroup but
>it seemingly didn't generate much interest.
>
>All objects that need to be finalized are registered somewhere with
>a special pool of references to these objects---call it "limbo".
>
>Now, the references to objects in "limbo" still count as live pointers
>to the collector, and therefore these objects, and any objects to
>which they refer, will still stay live and valid.
>
>When the *only* reference to some given object comes from this limbo
>pool---meaning that the rest of the program has effectively forgotten
>about it---the finalization procedure is run on this limbo object.
>
>When this finalization procedure is running, the object is still alive
>and perfectly valid, so there's no problem there.  After finalization
>is over, the reference to it is removed from limbo and so it now
>becomes real garbage, having already been finalized.

Or, if the finalization function stores a reference to the object in
another live structure, the finalized object is now an "ordinary" live
object (no resurrection problems) without doing anything extra at all.

>This scheme sounds too simple that somebody hasn't thought of it before.

Yes, we have implemented a finalization mechanism (in Chez Scheme)
that detects when an object should be finalized in essentially the
same manner as you describe (we call it a protected list, not limbo)
and have written it up in our paper "Guardians in a generation-based
collector", in the 1993 SIGPLAN PLDI conference.  One important
difference is that a finalization procedure is not executed
immediately for the object; rather, the collector puts objects to be
finalized on a queue that the application program can check explicitly
so that the application can decide when finalization actually occurs.
If finalization occurs at any point in a program when a collection can
occur, an application has to disable collections whenever resources
(e.g. mutable objects) shared by the application and finalization
procedures are manipulated (you essentially have a classic concurrent
update problem because the finalization code could be run at any point
in the application where a collection could be triggered,
e.g. function calls or allocation operations). Having a finalization
method associated with an object that is called at collection time
when the object is determined to be inaccessible is another example of
this very same problem.

A Guardian is a dynamically created object that encapsulates a
finalization queue in a procedure. Calling a guardian with an object
registers the object for finalization and calling the guardian with no
arguments returns the next object from the queue associated with the
guardian that needs to be finalized (or #f if there are none). Objects
can be registered with more than one guardian or more than one time
with the same guardian, or one guardian can even be registered with
another guardian without any problems. The only real tradeoff is that
if the application does not hang onto a pointer to the object after it
is returned by a guardian (the usual case in many applications), the
dead object is not reclaimed until after the next collection.  This
delay in reclaiming inaccessible objects appears to be the inherent
price of avoiding the problem with dangling references when the
finalization procedure is allowed access to the object. The paper
describes the collection algorithm, how to make it generation
friendly, and how guardians interact with weak pointers.

Carl
bruggema@cs.indiana.edu
