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.