[gclist] Finalization and death notices

[Boehm, Hans]

> From: Kerns, Bob [mailto:Bob.Kerns@firepond.com]

> You need to distinguish between death notices, and near-death notices.
> They're not the same thing.
> 
> I would agree that near-death notices can be used to 
> implement finalizers,
> and vice versa.
> 
> This is *not true* of death notices, as I understand them. 
> When a death
> notice is delivered, the object no longer exists.
I agree.  But I don't think the difference is terribly profound.  More
presisely, I think you can emulate one with the other if you add a level of
indirection.

Consider a big object A, for which I want to get a near-death notice.  I add
an object A' which contains only a ponter to A.  I hand out only pointers to
A'.  I arrange to get a death notice for A', making sure the death notice
includes a pointer to A.  If I want to "resurrect" the object, I allocate a
new A', call it A'', and hand out pointers to it.

Since finalization for a given object often requires access to some of its
state, I suspect this sort of thing will actually happen a fair amount.
That's why I'm not sure that "death notices" are universally a better idea
than the other options.  But I think that's only a performance issue.
> 
> My claim is that this is enough to implement all the *useful*
> characteristics of finalizers, without any of the not-so-good
> characteristics:
> 1) No revivification
> 2) No issues about whether to re-run the finalizer when a 
> revivified object
> again becomes unused.
I guess I never viewed this as a major problem.  I don't think so-called
"resurrection" causes any real problems.  The standard answer to the second
question is that the finalizer is only run once, possibly with an explicit
library call to cause it to be finalized again.
> 
> Another advantage of death notices is that --with no 
> cooperation from the
> object required-- any client can request notification. This 
> is something
> that finalizers don't give you, and can be used to do things 
> like implement
> structures like weak hash tables -- except you can directly 
> do much more
> general things, like for example remove entries from a 3D region-query
> database. To do the equivalent in Java, you'd have to add the code to
> Object's finalize() method, or more practically, have a weak 
> hash table on
> the side that you periodically check for things to remove.
That's an interesting point.  You can actually do that with the finalization
interface in our collector.  You register your own finalizer, and remember
to reregister the original one when you're done.  The restriction to one
finalizer per object really seems to be somewhat orthogonal, yet again.  In
Java 1.1 you could still do it by having each object provide a registration
interface for a list of finalization actions.  But that would require a
global convention. 

Hans