JDK-8319343 : Improve CDS module graph support for --add-modules option
Type:Sub-task
Component:hotspot
Sub-Component:runtime
Priority:P4
Status:Resolved
Resolution:Fixed
Submitted:2023-11-02
Updated:2024-11-11
Resolved:2024-10-31
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.
This added test test/hotspot/jtreg/runtime/cds/appcds/jigsaw/addmods/AddmodsOption.java which needs JVMCI is some parts (sets -XX:+EagerJVMCI). But Linuxppc64le has no JVMCI :
checking if platform is supported by JVMCI... no, ppc64le
checking if JVM feature 'jvmci' is available... no
So the test fails with "Unrecognized VM option 'EagerJVMCI'" .
A pull request was submitted for review.
Branch: master
URL: https://git.openjdk.org/jdk/pull/21553
Date: 2024-10-16 22:46:40 +0000
16-10-2024
Design update:
No changes in the creation of the jdk.module.addmods.<n> numbered property, e.g. with --add-modules modA,modB , only one jdk.module.addmods.0 property will be created with value "modA,modB".
Before dumping info the archive, all the module names from --add-modules will be sorted and then concatenated into one string with comma as the separator between module names.
During runtime, same function will be used to obtain the string in the same format with sorted module names. The string will be compared with the one from the archive to determine if the same module names were specified during dump time.
05-12-2023
Some design notes:
1) The --add-modules option and its value is being passed to the VM as is.
E.g. if the user specifies --add-modules modA,modB, the VM will receive the value of --add-modules as modA,modB and create a numbered property jdk.module.addmods.0 with value modA,modB
Enhancement will be made to have one numbered jdk.module.addmods property contain only one module name.
Duplicate modules will be ignored. E.g. if the user specifies --add-modules modA --add-modules modA, only one numbered jdk.module.addmods.0 property will be created with value modA.
With --add-modules modA,modB, currently one jdk.module.addmods.0 property is created. After this change, two numbered properties jdk.module.addmods.0=modA and jdk.module.addmods.1=modB
will be created.
Also extraneous commas will be stripped. E.g. with --add-modules ,,modA, , only the module name modA will be stored in the numbered property.
This is done in order for CDS to handle the module names more efficiently during dump time. And for comparing the ones specified during run time against the ones stored in the CDS archive.
2) Only unique module names will be stored in the CDS archive during dump time.
During runtime, checks will be performed on the module names from --add-modules against the ones stored in the CDS archive.
If the number of modules are not the same or the module names are not the same, full module graph will be disabled.
3) Corelib changes:
ModuleBootstrap.java
A Set<string> archiveRoots will be used to store all the modules specified via the -m and --add-modules. If any of the modules isn't in the runtime image, archiving will be disabled.
If --add-modules is specified and all the modules can be archived, a new Configuration will be created with the archiveRoots.
Check if there's any incubator modules will be done on the final Configuration. As before, ArchiveBootLayer.archive will not be call if there's any incubator module.
ArchivedModuleGraph.java
The constructor has an addition argument Set<String> addModules
The "get" method also has an addition argument Set<String> addModules. It returns the archivedModuleGraph only if both the mainModule and the addModules are the same as the input arguments.