RFR(L) 8244778 Archive full module graph in CDS
Ioi Lam
ioi.lam at oracle.com
Wed Jul 22 19:36:17 UTC 2020
https://bugs.openjdk.java.net/browse/JDK-8244778
http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v01/
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
HeapShared::reset_archived_object_states().
[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.
Thanks
- Ioi
More information about the core-libs-dev
mailing list