On Mon, 21 Jul 2025 17:51:34 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> 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. > > Ok, I see. At this point, you're just checking that what you've referred to > before loading the unnamed module matches what you've previously saved in the > shared archive. Did I get that right? Yes, it's checking that the Java and C++ code both found the same archived unnamed module. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26082#discussion_r2219925684
