-
Bug
-
Resolution: Fixed
-
P3
-
21, 22
-
b14
When an unknown JVMCI or Graal option is specified to libgraal, the VM can hang due to a deadlock within libgraal.
"JVMCI-native CompilerThread1" #15 [1243175] daemon prio=9 os_prio=0 cpu=7.02ms elapsed=151.86s tid=0x00007fb1bc02cb60 nid=1243175 runnable [0x00007fb1debfd000]
java.lang.Thread.State: RUNNABLE
Compiling: 186 4 java.util.Objects::requireNonNull (14 bytes)
at java.lang.Shutdown.halt0(java.base@22-internal/Native Method)
at java.lang.Shutdown.halt(java.base@22-internal/Shutdown.java:149)
- locked <0x0000000430801118> (a java.lang.Shutdown$Lock)
at java.lang.Shutdown.exit(java.base@22-internal/Shutdown.java:168)
- locked <0x00000007ff882098> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(java.base@22-internal/Runtime.java:188)
at java.lang.System.exit(java.base@22-internal/System.java:1916)
"JVMCI-native CompilerThread2" #16 [1243176] daemon prio=9 os_prio=0 cpu=3.34ms elapsed=151.86s tid=0x00007fb1b4006eb0 nid=1243176 waiting for monitor entry [0x00007fb1de9fd000]
java.lang.Thread.State: BLOCKED (on object monitor)
Compiling: 244 4 java.util.stream.AbstractPipeline::wrapSink (37 bytes)
at java.lang.Shutdown.exit(java.base@22-internal/Shutdown.java:166)
- waiting to lock <0x00000007ff882098> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(java.base@22-internal/Runtime.java:188)
at java.lang.System.exit(java.base@22-internal/System.java:1916)
The problem is that HotSpotJVMCIRuntime.vmEventListeners is lazily initialized and synchronizes on the HotSpotJVMCIRuntime instance. This can deadlock with other threads that synchronize on the same object.
"JVMCI-native CompilerThread1" #15 [1243175] daemon prio=9 os_prio=0 cpu=7.02ms elapsed=151.86s tid=0x00007fb1bc02cb60 nid=1243175 runnable [0x00007fb1debfd000]
java.lang.Thread.State: RUNNABLE
Compiling: 186 4 java.util.Objects::requireNonNull (14 bytes)
at java.lang.Shutdown.halt0(java.base@22-internal/Native Method)
at java.lang.Shutdown.halt(java.base@22-internal/Shutdown.java:149)
- locked <0x0000000430801118> (a java.lang.Shutdown$Lock)
at java.lang.Shutdown.exit(java.base@22-internal/Shutdown.java:168)
- locked <0x00000007ff882098> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(java.base@22-internal/Runtime.java:188)
at java.lang.System.exit(java.base@22-internal/System.java:1916)
"JVMCI-native CompilerThread2" #16 [1243176] daemon prio=9 os_prio=0 cpu=3.34ms elapsed=151.86s tid=0x00007fb1b4006eb0 nid=1243176 waiting for monitor entry [0x00007fb1de9fd000]
java.lang.Thread.State: BLOCKED (on object monitor)
Compiling: 244 4 java.util.stream.AbstractPipeline::wrapSink (37 bytes)
at java.lang.Shutdown.exit(java.base@22-internal/Shutdown.java:166)
- waiting to lock <0x00000007ff882098> (a java.lang.Class for java.lang.Shutdown)
at java.lang.Runtime.exit(java.base@22-internal/Runtime.java:188)
at java.lang.System.exit(java.base@22-internal/System.java:1916)
The problem is that HotSpotJVMCIRuntime.vmEventListeners is lazily initialized and synchronizes on the HotSpotJVMCIRuntime instance. This can deadlock with other threads that synchronize on the same object.