8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets #27880

iklam · 2025-10-17T22:20:12Z

By annotating SharedSecrets as @AOTSafeClassInitializer, we can avoid using the @AOTRuntimeSetup annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run.

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

Issue

JDK-8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets (Enhancement - P4)

Reviewers

Chen Liang (@liach - Reviewer) 🔄 Re-review required (review applies to a886aa85)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27880

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

Using diff file

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

Using Webrev

Link to Webrev Comment

…crets

bridgekeeper · 2025-10-17T22:22:00Z

👋 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-10-17T22:23:30Z

@iklam This change is no longer ready for integration - check the PR body for details.

openjdk · 2025-10-17T22:24:10Z

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

core-libs
hotspot-runtime
net
security

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-10-17T22:27:35Z

Webrevs

liach · 2025-10-18T02:48:42Z

src/java.base/share/classes/jdk/internal/access/SharedSecrets.java

+@AOTSafeClassInitializer
 public class SharedSecrets {
    // This field is not necessarily stable
    private static JavaAWTFontAccess javaAWTFontAccess;


Does aot initialization work with this field?

I think this field is safe. There are two places that could set it, but they will always set it to an instance of JavaAWTFontAccessImpl, which is stateless.

jdk/src/java.desktop/share/classes/java/awt/font/NumericShaper.java

Lines 148 to 149 in eff6439

if (SharedSecrets.getJavaAWTFontAccess() == null) {

SharedSecrets.setJavaAWTFontAccess(new JavaAWTFontAccessImpl());

jdk/src/java.desktop/share/classes/java/awt/font/TextAttribute.java

Lines 251 to 252 in eff6439

if (SharedSecrets.getJavaAWTFontAccess() == null) {

SharedSecrets.setJavaAWTFontAccess(new JavaAWTFontAccessImpl());

liach

Archiving the accessors should be fine.

DanHeidinga · 2025-10-20T13:51:18Z

src/java.base/share/classes/jdk/internal/access/SharedSecrets.java

 */

+// Static fields in this class are stateless, so the values initialized in the
+// AOT assembly phase can be safely cached.


Looking through the implementations of the Access classes, and I have concerns about:
setJavaObjectInputFilterAccess as it is implemented using a lambda:

SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);

Correct me if I'm wrong, but I believe that will cause the Config class to be AOTInitialized as well?

Config has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase.

There may be a similar issue with ObjectInputStream as well as I think this forces the class to be AOTInitialized.

SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString);

These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise?

Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?

Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null?

The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem

I looked at all the calls of the pattern SharedSecrets.set.*::

java/io/ObjectInputFilter.java: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); javax/crypto/SealedObject.java: SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream);

These calls are all done inside a <clinit>. In the four cases, only the first class (java.io.ObjectInputFilter.Config) has environment-dependent code inside its <clinit>.

Maybe we should mark the java.io.ObjectInputFilter.Config class with a new annotation AOTUnsafeClassInitializer (the opposite of the existing AOTSafeClassInitializer). If this class is initialized in the assembly phase, the VM will exit.

I think we can leave the other 3 cases alone.

An alternative is to rewrite the first case from:

SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2);

to

SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() { ObjectInputFilter createFilter2(String pattern) { return Config.createFilter2(pattern); } });

The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess:

SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() { public void checkArray(ObjectInputStream ois, Class<?> arrayType, int arrayLength) throws ObjectStreamException { ois.checkArray(arrayType, arrayLength); } public String readString(ObjectInputStream ois) throws IOException { return ois.readString(); } });

The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess.

I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE?

Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase?

@DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See CDSHeapVerifier::SharedSecretsAccessorFinder::do_field(). This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors.

minborg · 2025-10-27T08:48:40Z

src/hotspot/share/cds/cdsHeapVerifier.cpp

-      // This object carries no state and we can create a new one in the production run.
+    if (fd->signature()->starts_with("Ljdk/internal/access/") &&
+        fd->signature()->ends_with("Access;")) {
+      // The jdk/internal/access/*Access classes carry no states so they can be safely


This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface Access that the various access classes implement, and where we could document this and other constraints of the access classes.

I removed this hard-coded check and instead added CDSHeapVerifier::add_shared_secret_accessors(), which requires all AOT-initialized accessors to be stateless.

I also added a negative test case for SharedSecrets::javaObjectInputFilterAccess, which is not stateless so it cannot be initialized in the AOT assembly phase.

openjdk · 2025-10-28T03:59:30Z

@iklam hotspot has been added to this pull request based on files touched in new commit(s).

…otation-to-shared-secrets

8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSe…

a886aa8

…crets

openjdk bot added security [email protected] hotspot-runtime [email protected] core-libs [email protected] net [email protected] labels Oct 17, 2025

openjdk bot added the rfr Pull request is ready for review label Oct 17, 2025

liach reviewed Oct 18, 2025

View reviewed changes

liach approved these changes Oct 18, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Oct 18, 2025

DanHeidinga reviewed Oct 20, 2025

View reviewed changes

minborg reviewed Oct 27, 2025

View reviewed changes

Added StatelessOopsFinder

c6ea93c

openjdk bot added hotspot [email protected] and removed ready Pull request is ready to be integrated labels Oct 28, 2025

Merge branch 'master' into 8368199-add-aot-safe-class-initializer-ann…

6ae1172

…otation-to-shared-secrets

	if (SharedSecrets.getJavaAWTFontAccess() == null) {
	SharedSecrets.setJavaAWTFontAccess(new JavaAWTFontAccessImpl());

Uh oh!

8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets #27880

Are you sure you want to change the base?

8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets #27880

Uh oh!

Conversation

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

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Oct 17, 2025

Uh oh!

openjdk bot commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

liach left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

minborg Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Oct 28, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

5 participants

iklam commented Oct 17, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Oct 17, 2025 •

edited

Loading

openjdk bot commented Oct 17, 2025 •

edited

Loading

mlbridge bot commented Oct 17, 2025 •

edited

Loading

minborg Oct 27, 2025 •

edited

Loading