RFR: 8360555: Archive all unnamed modules in CDS full module graph
Coleen Phillimore
coleenp at openjdk.org
Thu Jul 17 12:39:51 UTC 2025
On Wed, 2 Jul 2025 00:18:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object.
>
> Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap.
>
> With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true.
>
> This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code.
>
> We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules.
src/hotspot/share/classfile/modules.cpp line 777:
> 775: if (CDSConfig::is_using_full_module_graph()) {
> 776: precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
> 777: unnamed_module->restore_archived_oops(boot_loader_data);
If you're restoring the module oop from the archive, what is the module oop passed into this that the rest of the code is using?
src/java.base/share/classes/jdk/internal/loader/BootLoader.java line 71:
> 69: }
> 70: jla.addEnableNativeAccess(UNNAMED_MODULE);
> 71: setBootLoaderUnnamedModule0(UNNAMED_MODULE);
Here it's being called. Should this be called?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213207332
PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213222965
More information about the core-libs-dev
mailing list