JEP 132: More-prompt finalization
peter.levart at gmail.com
Mon Jun 1 09:04:11 UTC 2015
On 06/01/2015 04:42 AM, Rezaei, Mohammad A. wrote:
> The problems start with the ReferenceQueue object and the heavy
> synchronization in it. Consider structures like j.u.WeakHashMap that
> need to expunge entries. If such structures are made somewhat
> concurrent, the lock in ReferenceQueue starts to become a serious problem:
> -In structures that are concurrent at the entry level (like jdk 8’s
> ConcurrentHashMap), if methods like get() or put() try to expunge, the
> lock in ReferenceQueue renders the structures non-concurrent.
The presented prototype changes the implementation of ReferenceQueue. It
doesn't use a lock any more for enqueu-ing when there are no waiters and
never for poll-ing. ReferenceQueue.poll() is a single volatile read when
queue is empty and a read followed by CAS when it is not (with retries
when contended). If there is a desire and new API could be extended, the
method like the following:
Iterator<Reference<? extends T>> pollChunk(int maxChunkSize);
...could return a chunk of enqueued references (or an empty iterator) so
that the reduced number of CAS instructions per de-queued reference
could be traded for the greater probability of retries because of
> -In structures that are multi-reader-single-writer locked, read
> methods cannot expunge (because they have to promote to a writer), but
> they can’t even check the queue, because that turns the multi-reader
> structure into a synchronized one.
By checking you mean poll() which also de-queues a reference if
available? What do you do when this happens. Would you need a peek()
> -In addition to expunge calls contending on the ReferenceQueue lock,
> ReferenceHandler thread can also contend on the same lock.
That's right. And in the presented prototype, this is minimized by
allowing ReferenceHandler thread to enqueue a chunk of pre-prepared
references in one go, minimizing the need to frequently notify any
possible waiters via a lock.notifyAll().
> -There is no fast clear() method on ReferenceQueue. That would be
> quite useful on a resize event.
This would be easy to implement if new API could be added.
> The above issues forced us to have a dedicated thread that does
> periodic expunging of References. This works ok under light load, but
> can fall behind under heavy load.
Because of the overhead/bottleneck of the reference processing I assume.
It would be great if you could check whether the prototype in webrev.02
improves your situation. It should be simple. Just compile the sources
and prepend the resulting classes to the bootclasspath of the JDK.
> Can you elaborate some more on what twists were necessary or what
> problems you had?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev