JDK-8218929 : [JVMCI] java.lang.IllegalCallerException: jdk.vm.ci.runtime is not open to module jdk.internal.vm.compiler
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: repo-metropolis
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-02-13
  • Updated: 2024-06-10
  • Resolved: 2019-03-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
repo-metropolisFixed
Related Reports
Relates :  
JDK-8218847 - [libgraal] port JVMCI support for libgraal
Description
During testing of JDK-8218847 changes I found few failures. This is one of them.

With "-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:-UseJVMCICompiler" flags
test/hotspot/jtreg/compiler/graalunit/DebugTest.java test failed with IllegalCallerException pointing to different modules:

org.graalvm.compiler.debug.test.TimerKeyTest started (4 of 5) 
  test2: FAILED 
test2(org.graalvm.compiler.debug.test.TimerKeyTest) 
java.lang.ExceptionInInitializerError 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.GraalServices.getThreadAllocatedBytes(GraalServices.java:243) 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.GraalServices.getCurrentThreadAllocatedBytes(GraalServices.java:255)
at org.graalvm.compiler.debug.test.TimerKeyTest.assumeManagementLibraryIsLoadable(TimerKeyTest.java:59) 
at org.graalvm.compiler.debug.test.TimerKeyTest.checkCapabilities(TimerKeyTest.java:51) 
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
... 
Caused by: java.lang.IllegalCallerException: jdk.vm.ci.hotspot.aarch64 is not open to module jdk.internal.vm.compiler 
at java.base/java.lang.Module.addOpens(Module.java:762) 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.GraalServices.openJVMCITo(GraalServices.java:125) 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.GraalServices$1$1.next(GraalServices.java:95) 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.GraalServices.loadSingle(GraalServices.java:147) 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.JMXService.<clinit>(JMXService.java:51) 

or 

Caused by: java.lang.IllegalCallerException: jdk.vm.ci.runtime is not open to module jdk.internal.vm.compiler 
at java.base/java.lang.Module.addOpens(Module.java:762) 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.GraalServices.openJVMCITo(GraalServices.java:125) 

or 

Caused by: java.lang.IllegalCallerException: jdk.vm.ci.code is not open to module jdk.internal.vm.compiler 
at java.base/java.lang.Module.addOpens(Module.java:762) 
at jdk.internal.vm.compiler@13-internal/org.graalvm.compiler.serviceprovider.GraalServices.openJVMCITo(GraalServices.java:125)
Comments
Changeset: b49b6a0d2a02 Author: kvn Date: 2019-03-20 15:54 -0700 URL: http://hg.openjdk.java.net/metropolis/dev/rev/b49b6a0d2a02
20-03-2019
Sounds like the right fix to me.
20-03-2019
The issue was that I removed static initialization of JVMCI class: http://hg.openjdk.java.net/jdk/jdk/file/18547cad9ec6/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java#l55 after Tom rewrote getRuntime() to be the only place which calls initializeRuntime(): https://github.com/graalvm/graal-jvmci-8/commit/a09e290b761d5b967265baf9409b5f6d7839126f#diff-e8101eae90827c3a372e04646d361b88 which is correct and I followed it. But for JDK version JVMCI.initialize() is still called from JDK9 version of GraalServices.java: https://github.com/oracle/graal/blob/master/compiler/src/org.graalvm.compiler.serviceprovider.jdk9/src/org/graalvm/compiler/serviceprovider/GraalServices.java#L92 Usually GraalServices.loadSingle() is not used for initialization except in debug/TTY.java and serviceprovider/JMXService.java and, as I understand, DebugTest.java uses TTY class. That is why only this test was affected. My suggested fix is to call JVMCI.getRuntime() instead of initialize() in openJVMCITo() shown above.
20-03-2019
This might be related: https://github.com/graalvm/graaljs/issues/123#issuecomment-470180240
06-03-2019
Got it. I will do that.
05-03-2019
It's as if JVMCI initialization not doing the package opening it's supposed to: http://hg.openjdk.java.net/metropolis/dev/file/09cbc7b886b9/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java#l123 I would debug through JVMCI initialization to find out why not.
03-03-2019
Maybe the use of GraalServices.getCurrentThreadAllocatedBytes?
01-03-2019
The strange thing is all other tests passed. What is special about this unit test?
01-03-2019
No I never evaluated this one. I assume we need to add a module reference somewhere but I don't know those come from. Maybe [~dnsimon] knows?
01-03-2019
[~never] you said you evaluated this too. Do you have a fix?
01-03-2019