-
Bug
-
Resolution: Fixed
-
P2
-
9, 10
-
b168
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8179752 | 10 | Douglas Simon | P2 | Resolved | Fixed | b07 |
jdk.internal.vm.compiler is a stripped down version of Graal. As Graal contains overlapped packages, Graal currently builds a module named `jdk.internal.vm.compiler` and replace the one in JDK using `--patch-module` to disable the hash check that is used to ensure only upgradeable modules to be upgraded [1]:
--upgrade-module-path=graal.jar \
--patch-module=jdk.internal.vm.compiler=.jar
The above will not work onceJDK-8177844 is resolved since jdk.internal.vm.compiler is not upgradeable. Graal should build a module with a different name e.g. `graal.vm.compiler` since jdk.internal.vm.compiler can't be upgraded.
Two possible solutions to explore:
1. Repackaging - this option is undesirable as it makes the merge process complicated.
2. Load graal.vm.compiler in a child layer and replace the ServiceLoader.load(Class, ClassLoader) call to load the JVMCI provider with ServiceLoader.load(Layer, Class)
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011413.html
--upgrade-module-path=graal.jar \
--patch-module=jdk.internal.vm.compiler=.jar
The above will not work once
Two possible solutions to explore:
1. Repackaging - this option is undesirable as it makes the merge process complicated.
2. Load graal.vm.compiler in a child layer and replace the ServiceLoader.load(Class, ClassLoader) call to load the JVMCI provider with ServiceLoader.load(Layer, Class)
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011413.html
- backported by
-
JDK-8179752 Need a mechanism to load Graal
- Resolved
- relates to
-
JDK-8186136 [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected
- Resolved
-
JDK-8177844 Ensure non-upgradeable modules cannot be upgraded even with --patch-module
- Resolved