JDK-8177845 : Need a mechanism to load Graal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-03-30
  • Updated: 2019-09-13
  • Resolved: 2017-04-28
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.
JDK 10 JDK 9
10Fixed 9 b168Fixed
Related Reports
Relates :  
JDK-8177844 - Ensure non-upgradeable modules cannot be upgraded even with --patch-module
Relates :  
JDK-8186136 - [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected
Description
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 once JDK-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
Comments
New mechanism allows to load Lab's Graal with JDK 9 which was not possible before without repackaging. It was verified by using Lab's Graal module with JDK 9 which has its own Graal module (jdk.internal.vm.compiler).
15-08-2017
Approved for JDK 9. You need also SQE approval before push.
19-04-2017
Fix Request This fix is required to make Graal an upgradeable module since the current mechanism for deploying upstream Graal in JDK 9 will not work once JDK-8177844 is integrated (see Description). See http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-April/026094.html for more details. Webrev: http://cr.openjdk.java.net/~dnsimon/8177845/
19-04-2017
As a result of offline discussion with [~alanb] and [~mchung], I'm making changes to Graal such that jdk.internal.vm.compiler can be made into an upgradeable module. The core idea is that all mechanisms for breaking into JDK internals (via use of jdk.internal.module.Modules) will be removed from Graal. In the few cases where Graal still needs JDK internals (e.g., jdk.internal.misc.VM.savedProps), JVMCI will have to provide a conduit.
07-04-2017
Thank you, Alan, for the update.
31-03-2017
This issue is a blocking issue. Mandy and I are discussing the issue with Doug to find a solution.
31-03-2017
Hi Doug [~dnsimon], as you know, we are now in Rampdown Phase 2 (RDP2) for JDK 9. If you want/can fix this bug in JDK 9, please request approval to integrate the fix. Otherwise please request deferral. Here is more information on the process: http://openjdk.java.net/projects/jdk9/rdp-2 JDK-8177673
31-03-2017
ILW=functionality disabled,experimental feature,no workaround=HLH=P2
31-03-2017
One proposal discussed with Doug and Alan with the child layer approach: JVMCI can take a path to find graal.vm.compiler module and its dependencies e.g. -XX:JVMCICompilerProviderPath=<graal-module-path> When JVMCI is initialized, it can create a layer to load modules from <graal-module-path> using Layer.boot.configuration().resolveAndBind(finder, ModuleFinder.of(), Set.of()); finder is the ModuleFinder for <graal-module-path>. The above will create a Configuration that resolves modules with an empty root set and it will do service binding and find the service providers of JVMCI if JVMCI is defined in the boot layer. Use ServiceLoader.load(Layer, Class) to find the providers in a given layer. ServiceLoader::stream allows you to select a specific Provider without instantiating it and select the provider from jdk.vm.internal.compiler or graal.vm.compiler. If -XX:JVMCICompilerProviderPath is not specified, JVMCI can use the boot layer to look up providers. I believe "jdk.vm.ci.services" package would need to be exported unconditionally (and in that case it might be better to rename back to jdk.vm.ci). Otherwise resolution may fail with: java.lang.module.ResolutionException: Module graal.vm.compiler does not read a module that exports jdk.vm.ci.services
30-03-2017