JDK-8207263 : Store the Configuration for system modules into CDS archive
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-07-13
  • Updated: 2019-09-10
  • Resolved: 2018-08-10
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 11 JDK 12
11.0.6Fixed 12 b07Fixed
Related Reports
Blocks :  
JDK-8209120 - Archive the Integer.IntegerCache
Relates :  
JDK-8202035 - Archive the set of ModuleDescriptor and ModuleReference objects for observable system modules with unnamed initial module
Relates :  
JDK-8207795 - Change VM.initializeFromArchive() to return a boolean
Relates :  
JDK-8194759 - Support caching class mirror objects
Relates :  
JDK-8209003 - Consolidate use of empty collections in java.lang.module
Description
The Configuration for the boot layer created by ModuleBootstrap.boot() (step 4) is a good candidate for archiving. Performance measurement shows archiving the Configuration gives another 1% - 1.5% startup gain when running HelloWorld from -cp.

Note: "step 4" can be found here in the source code
http://hg.openjdk.java.net/jdk/jdk/file/5afd528675f6/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java#l345
Comments
Fix Request Backporting this patch helps further improve JDK 11 startup time when the default CDS archive is enabled. Patch applies cleanly to 11u on top of JDK-8209003 patch.
14-08-2019
Performance data on an AMD x86_64 machine, Ubuntu 16.04, 2.8Ghz speed, 16 core, 96G RAM. Before: jdk.module.boot.4.resolveTime=4975566 After: jdk.module.boot.4.resolveTime=3730 time for i in {1..100}; do before/jdk/bin/java -cp hw.jar -Xshare:on HelloWorld; done real 0m11.759s user 0m12.704s sys 0m4.212s time for i in {1..100}; do after/jdk/bin/java -cp hw.jar -Xshare:on HelloWorld; done real 0m11.634s user 0m12.436s sys 0m3.960s The observed speed up for HelloWorld from -cp is about 1%.
19-07-2018
Archiving boot layer Configuration (including reachable objects from the Configuration) adds following classes to the list for initialization before the archived system module graph can be accessed at runtime: [3.645s][info ][cds,heap] Archived object klass (27): java.util.Collections$EmptyList in jdk.internal.module.ArchivedModuleGraph sub-graphs [3.645s][info ][cds,heap] Archived object klass (28): java.util.Collections$EmptyMap in jdk.internal.module.ArchivedModuleGraph sub-graphs [3.645s][info ][cds,heap] Archived object klass (29): java.lang.module.Configuration in jdk.internal.module.ArchivedModuleGraph sub-graphs [3.645s][info ][cds,heap] Archived object klass (30): java.lang.module.ResolvedModule in jdk.internal.module.ArchivedModuleGraph sub-graphs I have examined each class in above list. All of them do not have dependency on runtime context. They all look okay for archiving instances at dump time.
19-07-2018
The only complication for archiving Configuration is it's static field, EMPTY_CONFIGURATION. It's used as the parent for the boot layer Configuration. When boot layer Configuration is archived, we archive all reachable objects from it, which include the parent Configuration (the EMPTY_CONFIGURATION object created at dump time). If the static field, Configuration.EMPTY_CONFIGURATION is not archived and reinitialized from the archive at runtime, then there is an error at runtime because a different object is created and set in Configuration.EMPTY_CONFIGURATION field. This runtime created EMPTY_CONFIGURATION object is different from the archived boot Configuration parent object. Hence the error: Error occurred during initialization of boot layer java.lang.IllegalArgumentException: Parent of configuration != configuration of this Layer One solution is to archive the Configuration.EMPTY_CONFIGURATION field. At runtime reinitializes the field from the archived value. This guarantees that we only have a single EMPTY_CONFIGURATION instance in the entire system. That resolves the above error.
13-07-2018