Benefits of activeReferenceQueue (original) (raw)

Peter Levart peter.levart at gmail.com
Tue Jul 29 09:46:32 UTC 2014

On 07/29/2014 11:06 AM, Jaroslav Tulach wrote:

> >This is basically a re-implementation of ReferenceQueue.remove(int > >timeout) instance method in terms of a static method, which only briefly > >"touches" the queue instance wrapped in a Reference but majority of time > >it waits for notification while only holding a Reference to the queue. ... because as we look at the patch attached to issue: https://bugs.openjdk.java.net/browse/JDK-8051843 we can find out it uses very similar approach: https://bugs.openjdk.java.net/secure/attachment/21429/X.diff

Ah, sorry. The 'X.diff' was buried in the jira page so deep, I haven't noticed it before...

Yes, that's a clever way of doing this, but it can only be done by overriding a package-private enqueue() method unfortunately.

I have also played with the idea of overriding finalize() method on the ReferenceQueue subclass used in ActiveQueue and using it as a signal that the queue is about to go away, but there are issues involving unavoidable races since finalize() is called before WeakReference to the object is cleared and one can obtain a strong reference to the object which has already executed or is about to execute the finalize() method, making it 'alive' again, but wasting a single finalize() call-back each object gets in it's life...

Regards, Peter

> But that's only half of the story. The other half is how a thread finds

> >out that the queue has been collected so it can exit. Well, the patch https://bugs.openjdk.java.net/secure/attachment/21429/X.diff solves that by its + private static class Locks extends ReferenceQueue { + @Override + boolean enqueue(Reference<? extends Object> r) { + if (r instanceof Lock) { + synchronized (r) { + r.notifyAll(); + } + } + return false; + } + } part. As the test at the end of the patch shows, the solution behaves find. -jt

More information about the core-libs-dev mailing list