RFR(L) 8244778 Archive full module graph in CDS

Ioi Lam ioi.lam at oracle.com
Wed Jul 22 19:36:17 UTC 2020


Please review this patch that stores the full module graph in the CDS
archive heap. This reduces the initialization time of the basic JVM by
about 22%:

$ perf stat -r 100 bin/java -version
before: 98,219,329 instructions 0.03971 secs elapsed (+- 0.44%)
after:  55,835,815 instructions 0.03109 secs elapsed (+- 0.65%)

[1] Start with ModuleBootstrap.java. The current implementation is
     quite restrictive: the archived module graph is used only when no
     module options are specified.

     See ModuleBootstrap.mayUseArchivedBootLayer().

     We can probably support options such as main module and module path
     in a future RFE.

[2] In the current JDK implementation, there is no single object
     that represents "the module graph". Most of the information
     is stored in the archive bootLayer object, but a few additional
     restoration operations need to be performed:

     + See ModuleBootstrap.getArchivedBootLayer()
     + Some static fields need to be archived/restored in
       Module.java, BuiltinClassLoader.java, ClassLoaders.java
       and BootLoader.java

[3] I ran into a complication with two loader instances of
     PlatformClassLoader and AppClassLoader. They are stored in
     multiple tables inside the module graph (e.g.,
     BuiltinClassLoader$LoadedModule) so I cannot easily recreate
     them at runtime.

     However, these two loaders contain information specific to the
     dump time VM lifecycle (such as the classes that were loaded
     during CDS dumping) that need to be scrubbed. I couldn't find an
     elegant way of doing this, so I added a private "resetArchivedStates"
     method to a few classes. They are called inside

[4] Related native data structures (PackageEntry and ModuleEntry)
     are also archived. Start with classLoaderData.cpp

Passes mach5 tiers 1-4. I will test with additional tiers.

- Ioi

More information about the hotspot-runtime-dev mailing list