-
Bug
-
Resolution: Fixed
-
P4
-
23, 24
-
b26
Saw this exception in TypePollution.parallelInstanceOfInterfaceSwitch:
java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: Index -648 out of bounds for length 1000
at org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitch(TypePollution.java:147)
at org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitchLinearSCC(TypePollution.java:118)
at org.openjdk.bench.vm.lang.jmh_generated.TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.parallelInstanceOfInterfaceSwitchLinearSCC_avgt_jmhStub(TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.java:190)
at org.openjdk.bench.vm.lang.jmh_generated.TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.parallelInstanceOfInterfaceSwitchLinearSCC_AverageTime(TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.java:153)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:573)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:527)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:504)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:326)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:326)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1575)
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index -648 out of bounds for length 1000
at org.openjdk.bench.vm.lang.TypePollution.instanceOfInterfaceSwitch(TypePollution.java:195)
at org.openjdk.bench.vm.lang.TypePollution.lambda$parallelInstanceOfInterfaceSwitch$0(TypePollution.java:139)
at org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitch(TypePollution.java:145)
... 13 more
Turns out to be caused by the fact that Math.abs(Integer.MIN_VALUE) % 1000 == -648, and that the probe value will eventually come around to Integer.MIN_VALUE (after 2.9 billion or so probes).
The issue seems very rare on OOTB runs, but running iterations for a bit longer all but guarantees hitting this issue, e.g. make test TEST=micro:org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitch MICRO="OPTIONS=-r 20" throws the exception on the second iteration with some consistency on my M1 macbook.
Replacing Math.abs(probe) % objects.length with (probe & 0x7fffffff) % objects.length (or Math.floorMod(probe, objects.length)) might suffice if the exact distribution isn't all that important to the benchmark.
(Filed under hotspot/compiler since this came in withJDK-8180450)
java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: Index -648 out of bounds for length 1000
at org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitch(TypePollution.java:147)
at org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitchLinearSCC(TypePollution.java:118)
at org.openjdk.bench.vm.lang.jmh_generated.TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.parallelInstanceOfInterfaceSwitchLinearSCC_avgt_jmhStub(TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.java:190)
at org.openjdk.bench.vm.lang.jmh_generated.TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.parallelInstanceOfInterfaceSwitchLinearSCC_AverageTime(TypePollution_parallelInstanceOfInterfaceSwitchLinearSCC_jmhTest.java:153)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:573)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:527)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:504)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:326)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:326)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1575)
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index -648 out of bounds for length 1000
at org.openjdk.bench.vm.lang.TypePollution.instanceOfInterfaceSwitch(TypePollution.java:195)
at org.openjdk.bench.vm.lang.TypePollution.lambda$parallelInstanceOfInterfaceSwitch$0(TypePollution.java:139)
at org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitch(TypePollution.java:145)
... 13 more
Turns out to be caused by the fact that Math.abs(Integer.MIN_VALUE) % 1000 == -648, and that the probe value will eventually come around to Integer.MIN_VALUE (after 2.9 billion or so probes).
The issue seems very rare on OOTB runs, but running iterations for a bit longer all but guarantees hitting this issue, e.g. make test TEST=micro:org.openjdk.bench.vm.lang.TypePollution.parallelInstanceOfInterfaceSwitch MICRO="OPTIONS=-r 20" throws the exception on the second iteration with some consistency on my M1 macbook.
Replacing Math.abs(probe) % objects.length with (probe & 0x7fffffff) % objects.length (or Math.floorMod(probe, objects.length)) might suffice if the exact distribution isn't all that important to the benchmark.
(Filed under hotspot/compiler since this came in with
- relates to
-
JDK-8180450 secondary_super_cache does not scale well
- Resolved
- links to
-
Commit(master) openjdk/jdk/64e4aa21
-
Review(master) openjdk/jdk/22297