Background:
Several optional JVM features require internal modules:
+ EnableJVMCI requires jdk.internal.vm.ci
+ JFR requires jdk.jfr
+ -javaagent requires java.instrument
+ -Dcom.sun.management requires jdk.management.agent
Currently, these modules are added to the module graph only when the JVM feature is enabled by the command-line. E.g. (arguments.cpp),
if (status && (FlightRecorderOptions || StartFlightRecording)) {
if (!create_numbered_module_property("jdk.module.addmods", "jdk.jfr", _addmods_count++)) {
return false;
}
}
However, this cannot be efficiently supported by the AOTCache (CDS).
When the AOTCache is assembled, we store a copy of the boot layer (java.lang.System::bootLayer). When the AOTCache is loaded in a production run, we can reuse the cached boot layer if the production run uses the same set of modules as the AOTCache assembly phase.
By default, none of the above optional JVM features are enabled in the assembly phase. Therefore, the AOTCache does not include modules such as jdk.jfr.
In the production run, if the user decides to use JFR, the jdk.jfr module will be added. As a result we cannot use the cached boot layer. The boot layer must be created from scratch (by reading information about all required modules, etc), resulting in slower start-up time.
Further, if an AOTCache is created with -XX:+AOTClassLinking, the entire AOTCache will be rejected if the cached boot layer cannot be used
- The cached boot layer is used to ensure that the same set of classes are visible between assembly phase and production run, so that we can perform ahead-of-time resolution of symbolic references between the cached classes.
- Other cached heap objects may reference objects in the cached boot layer (e.g., java.lang.Class -> java.lang.Module). If we create the boot layer from scratch, such references will no longer be valid.
================================================
Proposal:
When an AOTCache is created, or when an AOTCache is loaded into a production run, the JVM automatically add the following four internal modules (if available from the module image) into the boot layer:
+ jdk.internal.vm.ci
+ jdk.jfr
+ java.instrument
+ jdk.management.agent
As a result, the AOTCache can be used whether optional JVM features (such as JFR) are enabled or not.
================================================
The size impact is minimal, as we store only meta information for the additional modules (not their classes) into the AOTCache.
$ java -XX:AOTMode=create -XX:AOTCache=baseline.aot -XX:AOTConfiguration=$JAVA_HOME/lib/classlist \
-p mlib/com.foo.jar -m com.foo/com.foo.Test
$ java -XX:AOTMode=create -XX:AOTCache=extra.aot -XX:AOTConfiguration=$JAVA_HOME/lib/classlist \
--add-modules=jdk.internal.vm.ci,jdk.jfr,java.instrument,jdk.management.agent \
-p mlib/com.foo.jar -m com.foo/com.foo.Test
$ ls -l *aot
-r--r--r-- 1 iklam iklam 15130624 Dec 10 23:37 baseline.aot
-r--r--r-- 1 iklam iklam 15138816 Dec 10 23:38 extra.aot
$ expr 15138816 - 15130624
8192