8360555: Archive all unnamed modules in CDS full module graph #26082

iklam · 2025-07-02T00:18:28Z

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, 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.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Warnings

⚠️ Patch contains a binary file (src/java.desktop/share/classes/javax/swing/beaninfo/images/JAppletColor16.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/javax/swing/beaninfo/images/JAppletColor32.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/javax/swing/beaninfo/images/JAppletMono16.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/javax/swing/beaninfo/images/JAppletMono32.gif)
⚠️ Patch contains a binary file (src/java.desktop/share/classes/javax/swing/doc-files/JRootPane-1.gif)

Issue

JDK-8360555: Archive all unnamed modules in CDS full module graph (Sub-task - P4)

Reviewers

Coleen Phillimore (@coleenp - Reviewer)
Vladimir Ivanov (@iwanowww - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26082/head:pull/26082
$ git checkout pull/26082

Update a local copy of the PR:
$ git checkout pull/26082
$ git pull https://git.openjdk.org/jdk.git pull/26082/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26082

View PR using the GUI difftool:
$ git pr show -t 26082

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26082.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-07-02T00:18:52Z

👋 Welcome back iklam! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-07-02T00:19:14Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2025-07-02T00:19:40Z

@iklam The following labels will be automatically applied to this pull request:

core-libs
hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-07-02T00:22:54Z

Webrevs

00: Full (6c261dcd)

coleenp · 2025-07-17T12:29:39Z

src/hotspot/share/classfile/modules.cpp

+#if INCLUDE_CDS_JAVA_HEAP
+  if (CDSConfig::is_using_full_module_graph()) {
+    precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
+    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) -- 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: #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), 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.

coleenp · 2025-07-17T12:36:52Z

src/java.base/share/classes/jdk/internal/loader/BootLoader.java

+            UNNAMED_MODULE = archivedClassLoaders.unnamedModuleForBootLoader();
+        } else {
+            UNNAMED_MODULE = jla.defineUnnamedModule(null);
+        }
        jla.addEnableNativeAccess(UNNAMED_MODULE);
        setBootLoaderUnnamedModule0(UNNAMED_MODULE);


Here it's being called. Should this be called?

coleenp

The code looks good.

coleenp · 2025-07-21T17:51:34Z

src/hotspot/share/classfile/modules.cpp

+#if INCLUDE_CDS_JAVA_HEAP
+  if (CDSConfig::is_using_full_module_graph()) {
+    precond(unnamed_module == ClassLoaderDataShared::archived_boot_unnamed_module());
+    unnamed_module->restore_archived_oops(boot_loader_data);


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?

openjdk · 2025-07-21T17:54:10Z

@iklam this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout 8360555-archive-all-unnamed-modules
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

iwanowww

Looks good.

8360555: Archive all unnamed modules in CDS full module graph

6c261dc

openjdk bot added the rfr Pull request is ready for review label Jul 2, 2025

openjdk bot added hotspot-runtime [email protected] core-libs [email protected] labels Jul 2, 2025

coleenp reviewed Jul 17, 2025

View reviewed changes

openjdk bot mentioned this pull request Jul 17, 2025

8350550: Preload classes from AOT cache during VM bootstrap #26375

Draft

3 tasks

coleenp approved these changes Jul 21, 2025

View reviewed changes

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Jul 21, 2025

iwanowww approved these changes Jul 21, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

8360555: Archive all unnamed modules in CDS full module graph #26082

8360555: Archive all unnamed modules in CDS full module graph #26082

iklam commented Jul 2, 2025 •

edited by openjdk bot

Loading

Uh oh!

bridgekeeper bot commented Jul 2, 2025

Uh oh!

openjdk bot commented Jul 2, 2025

Uh oh!

openjdk bot commented Jul 2, 2025

Uh oh!

mlbridge bot commented Jul 2, 2025

Uh oh!

coleenp Jul 17, 2025

Uh oh!

coleenp Jul 17, 2025

Uh oh!

iklam Jul 17, 2025

Uh oh!

coleenp Jul 21, 2025

Uh oh!

iklam Jul 21, 2025

Uh oh!

coleenp Jul 17, 2025

Uh oh!

coleenp left a comment

Uh oh!

coleenp Jul 21, 2025

Uh oh!

openjdk bot commented Jul 21, 2025

Uh oh!

iwanowww left a comment

Uh oh!

Uh oh!

8360555: Archive all unnamed modules in CDS full module graph #26082

Are you sure you want to change the base?

8360555: Archive all unnamed modules in CDS full module graph #26082

Conversation

iklam commented Jul 2, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Warnings

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Jul 2, 2025

Uh oh!

openjdk bot commented Jul 2, 2025

Uh oh!

openjdk bot commented Jul 2, 2025

Uh oh!

mlbridge bot commented Jul 2, 2025

Webrevs

Uh oh!

coleenp Jul 17, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Jul 17, 2025

Choose a reason for hiding this comment

Uh oh!

iklam Jul 17, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Jul 21, 2025

Choose a reason for hiding this comment

Uh oh!

iklam Jul 21, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp Jul 17, 2025

Choose a reason for hiding this comment

Uh oh!

coleenp left a comment

Choose a reason for hiding this comment

Uh oh!

coleenp Jul 21, 2025

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Jul 21, 2025

Uh oh!

iwanowww left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

iklam commented Jul 2, 2025 •

edited by openjdk bot

Loading