-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b107
A JVMCI compiler can cause deadlock or very slow execution in -Xbatch mode.
The two thread stacks below illustrate a scenario where the VM hung. The main thread is blocked on a compilation request being serviced by CompilerThread7 which happens to be in JVMCI initialization. This effectively means JVMCI compilation is single threaded.
CompilerThread7 is blocked on a lock held by main. This can be caused by one of 2 things:
1. As a result ofJDK-8145270, the main thread will timeout on the blocking compilation after about 2500ms. The main thread can then schedule another compilation that ends up acquiring the same lock that will once again block CompilerThread7 until the next blocking compilation timeout expires. In this pathological case, the compiler will only make progress very slowly. This can be largely mitigated by ensuring JVMCI compiler initialization happens eagerly early in the VM startup sequence if BackgroundCompilation is disabled.
2. There is a bug in the code that waits for a JVMCI compilation to make progress. It assumes that the CompileTask is still in the queue which may not be the case since AdvancedThresholdPolicy::select_task can remove stale tasks from the queue.
"main" #1 prio=5 os_prio=0 tid=0x00007fba48018000 nid=0x22c9 waiting on condition [0x00007fba51754000]
java.lang.Thread.State: RUNNABLE
JavaThread state: _thread_blocked
Thread: 0x00007fba48018000 [0x22c9] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
JavaThread state: _thread_blocked
at java.lang.String.equals(String.java:996)
at sun.net.www.protocol.file.Handler.openConnection(Handler.java:78)
- locked <0x00007fb235051430> (a sun.net.www.protocol.file.Handler)
at sun.net.www.protocol.file.Handler.openConnection(Handler.java:72)
- locked <0x00007fb235051430> (a sun.net.www.protocol.file.Handler)
at java.net.URL.openConnection(URL.java:1001)
at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:84)
at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41)
at java.net.URL.openConnection(URL.java:1001)
at java.net.URL.openStream(URL.java:1067)
at org.dacapo.harness.Benchmark.extractFileResource(Benchmark.java:599)
at org.dacapo.harness.Benchmark.prepareJars(Benchmark.java:229)
at org.dacapo.harness.Benchmark.initialize(Benchmark.java:211)
at org.dacapo.harness.Benchmark.<init>(Benchmark.java:184)
at org.dacapo.harness.Benchmark.<init>(Benchmark.java:194)
at org.dacapo.harness.Pmd.<init>(Pmd.java:31)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:426)
at org.dacapo.harness.TestHarness.runBenchmark(TestHarness.java:211)
at org.dacapo.harness.TestHarness.main(TestHarness.java:171)
at Harness.main(Harness.java:17)
"JVMCI CompilerThread7" #12 daemon prio=9 os_prio=0 tid=0x00007fba48173800 nid=0x22d5 waiting for monitor entry [0x00007fba4c221000]
java.lang.Thread.State: BLOCKED (on object monitor)
JavaThread state: _thread_blocked
Thread: 0x00007fba48173800 [0x22d5] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
JavaThread state: _thread_blocked
at sun.net.www.protocol.file.Handler.openConnection(Handler.java:72)
- waiting to lock <0x00007fb235051430> (a sun.net.www.protocol.file.Handler)
at java.net.URL.openConnection(URL.java:1001)
at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:84)
at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41)
at java.net.URL.openConnection(URL.java:1001)
at java.net.URL.openStream(URL.java:1067)
at java.util.ServiceLoader.parse(ServiceLoader.java:302)
at java.util.ServiceLoader.access$200(ServiceLoader.java:183)
at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:355)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:391)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:472)
at com.oracle.graal.hotspot.HotSpotHostBackend.completeInitialization(HotSpotHostBackend.java:99)
at com.oracle.graal.hotspot.HotSpotGraalRuntime.<init>(HotSpotGraalRuntime.java:158)
at com.oracle.graal.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:183)
at com.oracle.graal.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:51)
at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:288)
- locked <0x00007fb235bafcd0> (a jdk.vm.ci.hotspot.HotSpotJVMCIRuntime)
at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:332)
The two thread stacks below illustrate a scenario where the VM hung. The main thread is blocked on a compilation request being serviced by CompilerThread7 which happens to be in JVMCI initialization. This effectively means JVMCI compilation is single threaded.
CompilerThread7 is blocked on a lock held by main. This can be caused by one of 2 things:
1. As a result of
2. There is a bug in the code that waits for a JVMCI compilation to make progress. It assumes that the CompileTask is still in the queue which may not be the case since AdvancedThresholdPolicy::select_task can remove stale tasks from the queue.
"main" #1 prio=5 os_prio=0 tid=0x00007fba48018000 nid=0x22c9 waiting on condition [0x00007fba51754000]
java.lang.Thread.State: RUNNABLE
JavaThread state: _thread_blocked
Thread: 0x00007fba48018000 [0x22c9] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
JavaThread state: _thread_blocked
at java.lang.String.equals(String.java:996)
at sun.net.www.protocol.file.Handler.openConnection(Handler.java:78)
- locked <0x00007fb235051430> (a sun.net.www.protocol.file.Handler)
at sun.net.www.protocol.file.Handler.openConnection(Handler.java:72)
- locked <0x00007fb235051430> (a sun.net.www.protocol.file.Handler)
at java.net.URL.openConnection(URL.java:1001)
at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:84)
at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41)
at java.net.URL.openConnection(URL.java:1001)
at java.net.URL.openStream(URL.java:1067)
at org.dacapo.harness.Benchmark.extractFileResource(Benchmark.java:599)
at org.dacapo.harness.Benchmark.prepareJars(Benchmark.java:229)
at org.dacapo.harness.Benchmark.initialize(Benchmark.java:211)
at org.dacapo.harness.Benchmark.<init>(Benchmark.java:184)
at org.dacapo.harness.Benchmark.<init>(Benchmark.java:194)
at org.dacapo.harness.Pmd.<init>(Pmd.java:31)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:426)
at org.dacapo.harness.TestHarness.runBenchmark(TestHarness.java:211)
at org.dacapo.harness.TestHarness.main(TestHarness.java:171)
at Harness.main(Harness.java:17)
"JVMCI CompilerThread7" #12 daemon prio=9 os_prio=0 tid=0x00007fba48173800 nid=0x22d5 waiting for monitor entry [0x00007fba4c221000]
java.lang.Thread.State: BLOCKED (on object monitor)
JavaThread state: _thread_blocked
Thread: 0x00007fba48173800 [0x22d5] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
JavaThread state: _thread_blocked
at sun.net.www.protocol.file.Handler.openConnection(Handler.java:72)
- waiting to lock <0x00007fb235051430> (a sun.net.www.protocol.file.Handler)
at java.net.URL.openConnection(URL.java:1001)
at sun.net.www.protocol.jar.JarURLConnection.<init>(JarURLConnection.java:84)
at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:41)
at java.net.URL.openConnection(URL.java:1001)
at java.net.URL.openStream(URL.java:1067)
at java.util.ServiceLoader.parse(ServiceLoader.java:302)
at java.util.ServiceLoader.access$200(ServiceLoader.java:183)
at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:355)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:391)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:472)
at com.oracle.graal.hotspot.HotSpotHostBackend.completeInitialization(HotSpotHostBackend.java:99)
at com.oracle.graal.hotspot.HotSpotGraalRuntime.<init>(HotSpotGraalRuntime.java:158)
at com.oracle.graal.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:183)
at com.oracle.graal.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:51)
at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:288)
- locked <0x00007fb235bafcd0> (a jdk.vm.ci.hotspot.HotSpotJVMCIRuntime)
at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:332)
- relates to
-
JDK-8145270 Need to eagerly initialize JVMCI compiler under -Xcomp
-
- Resolved
-
-
JDK-8310673 [JVMCI] batch compilation for libgraal should work the same way as for C2
-
- Resolved
-
-
JDK-8148982 JVMCI: removed unnecessary acquisition of Threads_lock
-
- Closed
-
-
JDK-8310674 [JVMCI] batch compilation for libgraal should work the same way as for C2
-
- Closed
-