On Thu, 17 Jul 2025 12:29:39 GMT, Coleen Phillimore <cole...@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? If you're storing the unnamed module oop in the archive should this method not be called? If it is, what are you saving by archiving the unnamed module? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2213221120
