RER: Parallel object monitor scanning

[Zhengyu Gu]

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
>>>