On Thu, 17 Jul 2025 12:35:54 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> 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?
The callstack is:
jdk.internal.loader.BootLoader.setBootLoaderUnnamedModule0(java.base@26-internal/Native
Method)
jdk.internal.loader.BootLoader.<clinit>(java.base@26-internal/BootLoader.java:71)
jdk.internal.module.ModuleBootstrap.boot(java.base@26-internal/ModuleBootstrap.java:162)
java.lang.System.initPhase2(java.base@26-internal/System.java:1932)
Both the Java code and the native code have a handle to this unnamed module
oop. The `precond` checks that they indeed are pointing the same oop.
Also, even though the oop is archived, we still need to set up some native
states inside the `unnamed_module->restore_archived_oops(boot_loader_data)`
call. E.g., set up the `OopHandle` that binds the oop to the `ModuleEntry`.
---------------
> what are you saving by archiving the unnamed module?
It's for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)) -- I want
to be able to reference the unnamed module before executing any Java code, so
that archived classes can be loaded at the very beginning of
`vmClasses::resolve_all()`. See my draft PR:
https://github.com/openjdk/jdk/pull/26375
---------------
Currently, we still execute a lot of Java code when setting up the archived
module graph (inside `ModuleBootstrap.boot()`. I am working on a way to enable
the archived module graph without executing any Java code (which will be a few
REFs after [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550)), so this
call will eventually be gone.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2214437363
