JDK-8242264 : Archive packages defined by JVM_DefineModule in CDS
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2020-04-07
  • Updated: 2020-08-19
  • Resolved: 2020-06-15
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
tbdResolved
Related Reports
Duplicate :  
Description
This is the next step for JDK-8242296.

When defining modules via calls to JVM_DefineModule(), we see 596 PackageEntry objects being created, with a runtime overhead of ~250k to create and insert entries, another 300k instructions or so to validate input to Modules::define_modules. There's also the overhead in the Module java object constructor in extracting the package array from the module descriptor (~4% of executed bytecodes on Hello World)

If we could dump or build up package entries from existing information in CDS and coordinate with the API to load in the default module graph from the CDS archive, we might speed up this interaction a lot for the common case where we load the default module graph from CDS.

JVM_DefineModule() is called from the following Java call stack:
http://hg.openjdk.java.net/jdk/jdk/file/15d69d370743/src/java.base/share/classes/java/lang/Module.java#l136
java.lang.Module.defineModule0(Native Method)
java.lang.Module.<init>(Module.java:136)
java.lang.Module.defineModules(Module.java:1128)
java.lang.ModuleLayer.<init>(ModuleLayer.java:178)
java.lang.ModuleLayer.defineModules(ModuleLayer.java:664)
java.lang.ModuleLayer.defineModules(ModuleLayer.java:417)
jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:408)
java.lang.System.initPhase2(System.java:2070)

Comments
PackageEntries will be archived in JDK-8244778.
15-06-2020

A simplistic sketch of how the java part of the puzzle could be implemented: http://cr.openjdk.java.net/~redestad/scratch/pkg_from_archive.00/ On the VM end there are multiple options. Simplistically we can record the list of PackageEntry per module in the default configuration and use that in place of the GrowableArray created at L324-353 in modules.cpp. That'd get rid of the 4% work on the java side and all the String->char* conversions and verification on the VM side.
07-04-2020