JEP 132: More-prompt finalization (Re: Another take on Finalization)

[Rezaei, Mohammad A.]

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?

Thanks
Moh

>-----Original Message-----
>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
>Finalization)
>
>
>
>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
>welcome!
>> {
>> 	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.
>>
>> Thanks
>> Moh
>
>Isn't Reference.clear() what you are looking for?
>
>If a Reference is cleared before being discovered by GC, it will never
>be enqueued.
>
>Regards, Peter