RER: Parallel object monitor scanning

[Aleksey Shipilev]

Okay, push.

-Aleksey

On 11/23/2016 09:27 PM, Zhengyu Gu wrote:
> Ran with -p size=10,100,1000
> 
> Still showing 50+% improvement.
> 
> With patch:    
> http://cr.openjdk.java.net/~zgu/shenandoah/par-om/patched.txt
> Without patch: 
> http://cr.openjdk.java.net/~zgu/shenandoah/par-om/unpatched.txt
> 
> Okay to push?
> 
> 
> Thanks,
> 
> -Zhengyu
> 
> 
> On 11/23/2016 02:43 PM, Aleksey Shipilev wrote:
>> Ah, oops. Small sizes are not going to work, ignore them.
>>
>> -Aleksey
>>
>> On 11/23/2016 08:42 PM, Zhengyu Gu wrote:
>>> I got exception:
>>>
>>> java.lang.IndexOutOfBoundsException: Index 1 out-of-bounds for length 1
>>>      at
>>> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
>>>
>>>
>>>      at
>>> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
>>>
>>>
>>>      at
>>> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
>>>
>>>
>>>      at java.base/java.util.Objects.checkIndex(Objects.java:371)
>>>      at java.base/java.util.ArrayList.get(ArrayList.java:435)
>>>      at org.openjdk.Synchronizers.recursiveLock(Synchronizers.java:40)
>>>      at org.openjdk.Synchronizers.test(Synchronizers.java:34)
>>>      at
>>> org.openjdk.generated.Synchronizers_test_jmhTest.test_AverageTime(Synchronizers_test_jmhTest.java:164)
>>>
>>>
>>>      at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>>      at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>>
>>>      at
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>>
>>>      at java.base/java.lang.reflect.Method.invoke(Method.java:537)
>>>      at
>>> org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:453)
>>>
>>>
>>>      at
>>> org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:437)
>>>
>>>
>>>      at
>>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>>      at
>>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
>>>
>>>
>>>      at
>>> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>>      at
>>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161)
>>>
>>>
>>>      at
>>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>>>
>>>
>>>      at java.base/java.lang.Thread.run(Thread.java:844)
>>>
>>>
>>> -Zhengyu
>>>
>>>
>>> On 11/23/2016 01:46 PM, Aleksey Shipilev wrote:
>>>> On 11/23/2016 07:45 PM, Aleksey Shipilev wrote:
>>>>> On 11/23/2016 07:33 PM, Zhengyu Gu wrote:
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~zgu/shenandoah/par-om/webrev.00/index.html
>>>>>>
>>>>> Ok, good!
>>>>>
>>>>> Can you test this with lower number of monitors, e.g. set -p
>>>>> count=1,10,100,1000? This will assert we don't have the regression for
>>>>> the usual case.
>>>> Sorry, the parameter name is "size", of course, so:
>>>>
>>>> $ java -jar target/benchmarks.jar --jvmArgs "-XX:+UseShenandoahGC
>>>> -Xlog:gc+stats" -p size=1,10,100,1000
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>