Hi again,
On 06/29/2016 03:30 PM, Peter Levart wrote:
Just to show what I mean, here's a simple optimization that doesn't
use a private pendingList of references shared among callers of
tryHandlePanding(true/false), but instead uses course-grained
synchronization and waiting for tryHandlePanding(false) callers while
ReferenceHandler is privately processing the whole list of pending
references:
http://cr.openjdk.java.net/~plevart/misc/PendingReferenceHandling/webrev.02/
...and now, on top of above, for some more involved optimization that is
most effective when a chunk of pending references is discovered where
majority are destined for the same ReferenceQueue (as in our benchmark):
http://cr.openjdk.java.net/~plevart/misc/PendingReferenceHandling/webrev.03/
The results of benchmark:
Original JDK 9:
Benchmark (refCount) Mode Cnt
Score Error Units
ReferenceEnqueueBench.dequeueReferences 100000 ss 100 38410.515
± 1011.769 us/op
Patched (by Kim):
Benchmark (refCount) Mode Cnt
Score Error Units
ReferenceEnqueueBench.dequeueReferences 100000 ss 100 42197.522
± 1161.451 us/op
Proposed (by Peter, webrev):
Benchmark (refCount) Mode Cnt
Score Error Units
ReferenceEnqueueBench.dequeueReferences 100000 ss 100 34134.977
± 1274.753 us/op
Proposed (by Peter, webrev.02):
Benchmark (refCount) Mode Cnt
Score Error Units
ReferenceEnqueueBench.dequeueReferences 100000 ss 100 27935.929
± 1128.678 us/op
Proposed (by Peter, webrev.03):
Benchmark (refCount) Mode Cnt Score
Error Units
ReferenceEnqueueBench.dequeueReferences 100000 ss 100 6603.009
± 59.051 us/op
That's already 6x faster than baseline!
I'm not suggesting that any of these optimizations is applied. I just
wanted to show that a JNI call that allows retrieving the whole pending
list has potential to allow such optimizations.
Regards, Peter
