[gclist] Finalization and death notices

kkonaka@softalia.com kkonaka@softalia.com
Wed, 10 Oct 2001 12:10:23 -0400


hi! thanks all,

 > Anyway, Java 2 has three Reference classes, all of which can be
 > enqueued - and the other two, SoftReference and WeakReference, are
 > handled _before_ the finalizers.  So you could probably use those.
 > See <http://www.memorymanagement.org/glossary/s.html#soft.reference>
 > and <http://www.memorymanagement.org/glossary/w.html#weak.reference>
 > for details.

okay - looks like I was not much aware of the difference between

 1) when referent objects are finalized.
 2) when reference objects themselves are enqueued.
 3) when reference objects' refs to the referent objects are cleared.

...the documentation actually never appears to specify 
which one of 1) and 2) _completes_ first; only to say
 <<the objects are declared as ``finalizable''>>.

but as to 2) vs. 3), PhantomReference seems to be the only one
in which 2) happens before 3):

http://java.sun.com/j2se/1.3/docs/api/java/lang/ref/package-summary.html
 | 
 |   Automatically-cleared references
 |   
 |    Soft and weak references are automatically cleared by the collector
 |    before being added to the queues with which they are registered, if
 |    any. Therefore soft and weak references need not be registered with a
 |    queue in order to be useful, while phantom references do. An object
 |    that is reachable via phantom references will remain so until all such
 |    references are cleared or themselves become unreachable.


 > In fact, I'm surprised you got anywhere with PhantomReference, since
 > get is always supposed to return null on it.  I think you're on the
 > wrong track here.

I'm still wondering if there's any other way around...

 > The WeakReference sounds like what you want, _but_ the WeakReference
 > may not be enqueued until after the finalizer runs.  So I think the
 > only solution in Java is to redefine finalize() on the TargetClass, as
 > you mention in your advanced-java message.

for this, what I've done in the actual implementation is to ``remember''
how many times the objects have came back to the cache (that's what I
was trying to do by the way); and call finalize() explicitly after the
2nd time and after. - doing this requires some additional +20 lines
amount of code, and didn't much like this; that's actually the part of
the reason I was wondering about the presence of some `variant' of
current PhantomReference...

regards,
kenji