Benefits of activeReferenceQueue

[Jaroslav Tulach]

Dne Út 29. července 2014 18:16:24, David Holmes napsal(a):
> Thanks for the detailed explanation. It is an interesting problem. 

Good. I am glad it attracted your attention. I am also glad Peter came with 
his static method...

> On 29/07/2014 6:03 PM, Peter Levart wrote:
> > On 07/29/2014 04:16 AM, David Holmes wrote:
> >> Hi Jaroslav,
> >> 
> >> So ... activeReferenceQueue is a reference queue that embodies a
> >> thread that does the polling and implements a psuedo-finalization
> >> mechanism. This works fine in the normal case where the lifetime of
> >> the queue is the lifetime of the "application". In the WAR case (and I
> >> don't know the details of WAR deployment) each time it is deployed in
> >> the same VM we get a new activeReferenceQueue and a new thread.
> >> 
> >> The basic issue is that the thread has a strong reference to the queue
> >> and has no idea when it should exit and so the thread and queue remain
> >> forever even if there is no user code with a reference to the queue -
> >> does that sum it up?
> >> 
> >> Can the thread not hold a weakreference to the queue and poll using
> >> remove(timeout) and then terminate when the queue reference is gone?
> >> 
> >> Thanks,
> >> David
> > 
> > The main problem I think is, that when calling queue.remove(timeout) the
> > thread *does* hold a strong reference to the queue for the entire time
> > it waits for something to be enqueued. So majority of time in a loop,
> > thread holds a strong reference to queue preventing it from being
> > considered for WeakReference processing or at least prolonging it's life
> > into an indefinite future (the window of opportunity for queue to be
> > found weakly reachable is very small).
> > 
> > That's why Jaroslav is hacking with reflection to get hold of the 'lock'
> > so that he can re-implement the ReferenceQueue.remove(timeout) method
> > without holding a strong reference to the queue. If we wanted to make
> > Jaroslav's life easier, a method like the following in ReferenceQueue
> > could help him:
> > 
> > 
> > public class ReferenceQueue {
> > 
> >      ...
> >      
> >      public static class CollectedException extends Exception {}
> >      
> >      public static <T> Reference<? extends T> remove(
> >      
> >          Reference<? extends ReferenceQueue<T>> queueRef,
> >          long timeout
> >      
> >      ) throws IllegalArgumentException, InterruptedException,
> > 
> > CollectedException {
> > 
> >          if (timeout < 0) {
> >          
> >              throw new IllegalArgumentException("Negative timeout value");
> >          
> >          }
> >          // obtain lock
> >          Object lock = apply(queueRef, queue -> queue.lock);
> >          
> >          synchronized (lock) {
> >          
> >              Reference<? extends T> r = apply(queueRef,
> > 
> > ReferenceQueue<T>::reallyPoll);
> > 
> >              if (r != null) return r;
> >              long start = (timeout == 0) ? 0 : System.nanoTime();
> >              for (; ; ) {
> >              
> >                  lock.wait(timeout);
> >                  r = apply(queueRef, ReferenceQueue<T>::reallyPoll);
> >                  if (r != null) return r;
> >                  if (timeout != 0) {
> >                  
> >                      long end = System.nanoTime();
> >                      timeout -= (end - start) / 1000_000;
> >                      if (timeout <= 0) return null;
> >                      start = end;
> >                  
> >                  }
> >              
> >              }
> >          
> >          }
> >      
> >      }
> >      
> >      private static <R, T> R apply(
> >      
> >          Reference<? extends ReferenceQueue<T>> queueRef,
> >          Function<ReferenceQueue<T>, R> func
> >      
> >      ) throws CollectedException {
> >      
> >          ReferenceQueue<T> queue = queueRef.get();
> >          if (queue == null) throw new CollectedException();
> >          return func.apply(queue);
> >      
> >      }
> >      
> >      ...
> > 
> > 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

 > 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<Object> {
+        @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