JDK-8266329 : Improve CDS module graph support for command-line options
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2021-04-29
  • Updated: 2024-06-21
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
tbdUnresolved
Related Reports
Relates :  
JDK-8316448 - [JVMCI] Do not load jdk.internal.vm.ci automatically if UseJVMCINativeLibrary is true
Relates :  
JDK-8310108 - Skip ReplaceCriticalClassesForSubgraphs when EnableJVMCI is specified
Relates :  
JDK-8247449 - Revisit the argument processing logic for MetaspaceShared::disable_optimized_module_handling()
Relates :  
JDK-8223077 - module path support for dynamic CDS archive
Relates :  
JDK-8315127 - CDSMapTest fails with incorrect number of oop references
Sub Tasks
JDK-8316969 :  
Improve CDS module graph support for --module option - Resolved
JDK-8319343 :  
Improve CDS module graph support for --add-modules option - Closed
JDK-8328313 :  
Archived module graph should allow identical --module-path to be specified during dump time and run time - Open
Description
Currently, the CDS archived full module graph (FMG, implemented in JDK-8244778) is disabled when you specify command-line options that are related to the module system.

We should improve CDS so that we can still take advantage of the FMG when certain command-line options are specified. Here are a few possibilities to consider:

1. At runtime, --add-modules is specified.

One common scenario is when -XX:+EnableJVMCI is specified, we automatically add the jdk.internal.vm.ci module.

We should try to load the FMG, and then add the extra modules as specified.

2. At runtime, --module is specified.

This limits the number of modules visible in the boot layer. We should load the FMG from CDS, and then trim out the unwanted modules.

3. At dump time, --module is specified

This limits the number of modules visible in the boot layer. At runtime, we require that the same --module must be specified in order to load the FMG.

4. At runtime, --module-path is specified.

We should load the FMG from CDS, and then add the extra modules.

5. At dump time, --module-path is specified

We should dump the FMG with the extra modules. At run time, we require that --module-path is the same as (or a superset of) the dump time --module-path in order to load the FMG.

This RFE can be implemented in several steps (to be tracked as subtasks of this RFE).
Comments
> why don't we always add jdk.internal.vm.ci to module graph by default As of JDK-8298099, there's no need for loading jdk.internal.vm.ci when using libgraal.
21-06-2024
If the JDK is built with libgraal support, why don't we always add jdk.internal.vm.ci to module graph by default? This can be done by unconditionally adding jdk.internal.vm.ci to the generated file ./support/gensrc/java.base/jdk/internal/module/ModuleLoaderMap.java (depending on what options were passed to the configure script). That way we don't need to programmatically add this module in arguments.cpp: https://github.com/openjdk/jdk/blob/880e458a1072589ae199cc9204dcce9eab0f4eaa/src/hotspot/share/runtime/arguments.cpp#L1788-L1794
21-06-2024
Mapping it to the platform class loader should be okay, as long as there is isn't a module mapped to the boot loader that requires it. The SM is still a supported execution mode so it means you will need to tweak the security policy to grant the module permissions, but I think you know that already.
23-01-2024
[~dnsimon] JDK-8319343 (module graph support for --add-modules) should be able to handle modules in the platform class loader.
23-01-2024
[~iklam] we're thinking of pulling JVMCI out of the boot class loader and into the platform class loader (JDK-8323832). How would that impact this issue?
22-01-2024
Hi Ioi, I opened JDK-8316448 to try mitigate the cost of non-FMG for libgraal. However, [~chumer] reminded me that even with libgraal enabled, Truffle still requires loading the Java JVMCI module (and will do so for a while). Naturally, Truffle also wants the startup benefits of FMG. All this to say that it would be great to see this issue resolved before too long ;-)
25-09-2023
I have merged https://github.com/openjdk/jdk/pull/14485 that skips ReplaceCriticalClassesForSubgraphs in the presence of +EnableJVMCI. Please revert that change once this issue is resolved.
13-07-2023