It sometimes fails like this, most often on windows:

stdout: [Error parsing JVMCI options: Could not find option jvmci.XXXXXXXXX
Error: A fatal exception has occurred. Program will exit.
];
 stderr: [Runtime.exit(1) logging failed: Cannot invoke "java.lang.Module.getClassLoader()" because "this.val$m" is null
]
 exitValue = 1

java.lang.RuntimeException: stderr was not empty
at jdk.test.lib.process.OutputAnalyzer.stderrShouldBeEmpty(OutputAnalyzer.java:132)
at TestInvalidJVMCIOption.main(TestInvalidJVMCIOption.java:52)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
at java.base/java.lang.Thread.run(Thread.java:1570)

Adding some debugging code shows that sometimes the module field of classes in java.base haven't been updated at the point of execution.

java.lang.InternalError: null module for class java.lang.Shutdown
at java.base/java.lang.System.getLogger(System.java:1828)
at java.base/java.lang.Shutdown.logRuntimeExit(Shutdown.java:177)
at java.base/java.lang.Shutdown.exit(Shutdown.java:160)
at java.base/java.lang.Runtime.exit(Runtime.java:188)
at java.base/java.lang.System.exit(System.java:1927)

This seems like a minor initialization ordering problem. We permit the native JIT to start compiling methods somewhat early in the bootstrap process but that's probably too early to call exit so it might need to wait until bootstrap is further along to do so.