RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Peter Levart peter.levart at gmail.com
Wed Jun 29 15:19:09 UTC 2016


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



More information about the hotspot-dev mailing list