In JDK-8298099, we have decoupled libgraal from jdk.internal.vm.ci.
However, since JDK 23, with the Oracle JDK, you can enable libgraal with one of the following:
java -XX:+UnlockExperimentalVMOptions ...
java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler ...
In both cases, EnableJVMCI is set to true:
https://github.com/openjdk/jdk/blob/cc628a133e471e7edf07831ff386f0eaf57e9bff/src/hotspot/share/jvmci/jvmci_globals.cpp#L65
https://github.com/openjdk/jdk/blob/cc628a133e471e7edf07831ff386f0eaf57e9bff/src/hotspot/share/jvmci/jvmci_globals.cpp#L89
This causes the following code to be executed in arguments.cpp to add the jdk.internal.vm.ci module.
if (status && EnableJVMCI) {
PropertyList_unique_add(&_system_properties, "jdk.internal.vm.ci.enabled", "true",
AddProperty, UnwriteableProperty, InternalProperty);
if (ClassLoader::is_module_observable("jdk.internal.vm.ci")) {
if (!create_numbered_module_property("jdk.module.addmods", "jdk.internal.vm.ci", _addmods_count++)) {
return false;
}
}
}
Since libgraal doesn't require the jdk.internal.vm.ci module, it should not be resolved implicitly when -XX:+UseGraalJIT is specified.
====================
Justification:
Since JDK 483, many more CDS optimizations are enabled when -XX:+AOTClassLinking is specified (see numbers in https://bugs.openjdk.org/browse/JDK-8342279). However, these optimizations require the archived module graph to be used. Today, if you enable UseGraalJIT, the archived module graph will be disabled. As a result, the *entire* CDS archive will be disabled. This will result in slower start-up time when UseGraalJIT is enabled.
(A work-around is to run with "-Xshare:dump --add-modules=jdk.internal.vm.ci -XX:+AOTClassLinking", but the the resulting CDS archive cannot be used when UseGraalJIT is disabled)
By avoiding the implicit-add of jdk.internal.vm.ci, the CDS archive will work out-of-the-box, whether UseGraalJIT is enabled or not.
However, since JDK 23, with the Oracle JDK, you can enable libgraal with one of the following:
java -XX:+UnlockExperimentalVMOptions ...
java -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler ...
In both cases, EnableJVMCI is set to true:
https://github.com/openjdk/jdk/blob/cc628a133e471e7edf07831ff386f0eaf57e9bff/src/hotspot/share/jvmci/jvmci_globals.cpp#L65
https://github.com/openjdk/jdk/blob/cc628a133e471e7edf07831ff386f0eaf57e9bff/src/hotspot/share/jvmci/jvmci_globals.cpp#L89
This causes the following code to be executed in arguments.cpp to add the jdk.internal.vm.ci module.
if (status && EnableJVMCI) {
PropertyList_unique_add(&_system_properties, "jdk.internal.vm.ci.enabled", "true",
AddProperty, UnwriteableProperty, InternalProperty);
if (ClassLoader::is_module_observable("jdk.internal.vm.ci")) {
if (!create_numbered_module_property("jdk.module.addmods", "jdk.internal.vm.ci", _addmods_count++)) {
return false;
}
}
}
Since libgraal doesn't require the jdk.internal.vm.ci module, it should not be resolved implicitly when -XX:+UseGraalJIT is specified.
====================
Justification:
Since JDK 483, many more CDS optimizations are enabled when -XX:+AOTClassLinking is specified (see numbers in https://bugs.openjdk.org/browse/JDK-8342279). However, these optimizations require the archived module graph to be used. Today, if you enable UseGraalJIT, the archived module graph will be disabled. As a result, the *entire* CDS archive will be disabled. This will result in slower start-up time when UseGraalJIT is enabled.
(A work-around is to run with "-Xshare:dump --add-modules=jdk.internal.vm.ci -XX:+AOTClassLinking", but the the resulting CDS archive cannot be used when UseGraalJIT is disabled)
By avoiding the implicit-add of jdk.internal.vm.ci, the CDS archive will work out-of-the-box, whether UseGraalJIT is enabled or not.
- relates to
-
JDK-8298099 [JVMCI] decouple libgraal from JVMCI module at runtime
- Resolved
-
JDK-8345969 AOTCache should always include internal modules required for optional JVM features
- New