JEP 132: More-prompt finalization (Re: Another take on Finalization)
Rezaei, Mohammad A.
Mohammad.Rezaei at gs.com
Mon Jun 8 17:45:05 UTC 2015
If that's the case, the documentation needs to be more clear :-) It currently says:
"Clears this reference object. Invoking this method will not cause this object to be enqueued."
I interpret that as meaning the reference will not be put on the queue as a part of the clear() call.
The bit of code that prevents this queuing is nowhere to be seen and a naïve reading of the rest of the code suggests it will be queued:
ReferenceQueue q = r.queue;
if (q != ReferenceQueue.NULL) q.enqueue(r);
I don't recall seeing clear() mentioned anywhere. A quick search through the jdk code shows hundreds of usages of WeakReference, but only a handful of calls to clear(). It's missing from places I would consider prime usage sites, e.g. WeakHashMap.
Maybe we could even add this.queue = ReferenceQueue.NULL in clear() to avoid confusion?
>From: Peter Levart [mailto:peter.levart at gmail.com]
>Sent: Monday, June 08, 2015 1:07 PM
>To: Rezaei, Mohammad A. [Tech]
>Cc: 'hotspot-gc-dev at openjdk.java.net openjdk.java.net'; 'core-libs-
>dev at openjdk.java.net'
>Subject: Re: JEP 132: More-prompt finalization (Re: Another take on
>On 06/08/2015 06:53 PM, Rezaei, Mohammad A. wrote:
>> Shouldn't we extend the same notion to other reference types? For Weak/Soft
>references, the (rough) equivalent would be a method of the kind:
>> public void markUnqueueable() // suggestions for better method name most
>> this.q = ReferenceQueue.NULL;
>> This is quite useful when the reference is cleaned up before the referent is
>GC'ed, which happens, for example, when rehashing a weak map.
>Isn't Reference.clear() what you are looking for?
>If a Reference is cleared before being discovered by GC, it will never
More information about the hotspot-gc-dev