https://bugs.openjdk.java.net/browse/JDK-8244778 http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v0... 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