RFR: 8360555: Archive all unnamed modules in CDS full module graph

[Coleen Phillimore]

On Thu, 17 Jul 2025 12:29:39 GMT, Coleen Phillimore <coleenp 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?

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