[gclist] Finalization and the insane postman bug.

[Charles Fiterman]

At 04:14 PM 10/10/01 -0400, you wrote:
>Some people like "death notices" instead of finalizers.  A "death
>notice" is a message placed by the collector when it frees an object,
>which a live object can later read and take action on.
>java.lang.ref.PhantomReference is one way of implementing this: it's a
>lot like a weak reference (i.e. it doesn't keep the object from being
>collected and you get notified when the object has been collected)
>except that you can't dereference it, ever, even when the object
>exists.

The proposed implementation of notices is they are objects queued on a
double linked list. The collector is informed of them and removes them from
the list they are on and puts them on another list designated in the
notice. The user can always traverse the first list. Notices all contain a
weak reference to the object. With death notices this reference is zeroed
when the object goes out of scope. With near death notices it becomes a
strong reference.

A death notice is not a message placed by the collector, its a message
moved from one queue to another by the collector after being modified.

>Death notices share problems 1 and 4 with finalizers, but avoid
>problems 2 and 3.  They make problem 5 worse, because the file
>descriptor allocator also needs to invoke the application's
>file-descriptor-death-notice-queue-reading code --- which also brings
>back problem 2 with a vengeance --- or fail.  (Unless that code is
>runnable in another thread, in which case the file descriptor
>allocator just needs to wait until it's done.)

Death notices do not share problem 1 object retention. When an object is
out of scope it is killed. Death notices give problem 4 what to do at end
of (job, phase 3 etc) to the user. The user should be able to traverse
unsent notices at will. The same is true of problem 5 (various subsystems
needing to be aware of outstanding death notices.)

>Death notices can be implemented on top of finalizers.  Finalizers
>cannot be implemented on top of death notices, because a finalizer has
>access to the dead object, and a death notice does not.
>
>In the halfway ground, there are near-death notices, where you have an
>'owner' object with a reference to the victim object, and the GC
>notifies the 'owner' object when that reference becomes the only
>reference to the victim object.  The 'owner' object can then release
>resources associated with the victim object before it releases its own
>reference, causing that object to be finally collected.
>
>Near-death notices share problems 1, 3, and 4 with finalizers, and
>partly share problem 2.  They make it easier because the mutator can
>wait until it doesn't hold any locks to handle near-death notices,
>even without being multithreaded.  Also, they remove the semantic
>contradictions surrounding normal finalizers, such as "resurrection".
>
>They make problem 5 worse in the same way that death notices do.

Indeed near death notices share problem 1 and 3 (object retention and
resurection) TNABTAF that's their purpose. But they do it in a clean
transparent fashion and only when the user clearly wants it. They make it
the users job to figure out the context and order, TNANTAF that's the
point, nobody else has a chance. Properly implemented they don't share 4
and 5 (the user not knowing what's out there at various times).