8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache #27553

ashu-mehra · 2025-09-29T16:22:45Z

This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded.

Testing:
Before this patch runtime/cds/appcds/aotClassLinking/StringConcatStress.java emits warning messages in the production run:

[0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL'
[0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache
[0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII'
[0.009s][warning][aot                ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache

With this patch, such warnings are not seen at all

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-8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache (Enhancement - P4)

Reviewers

Vladimir Kozlov (@vnkozlov - Reviewer)
Ioi Lam (@iklam - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27553

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

Using diff file

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

Using Webrev

Link to Webrev Comment

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

bridgekeeper · 2025-09-29T16:24:03Z

👋 Welcome back asmehra! 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-09-29T16:24:32Z

@ashu-mehra This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache

Reviewed-by: kvn, iklam

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 118 new commits pushed to the master branch:

3f27a03: 8368727: CDS custom loader support causes asserts during class unloading
1d55ade: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark
3d113af: 8369051: More small Float16 refactorings
... and 115 more: https://git.openjdk.org/jdk/compare/5d93242028dfc68b838a8efb0fbc4de3fea7fa0d...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-09-29T16:25:18Z

@ashu-mehra The following label will be automatically applied to this pull request:

hotspot

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

mlbridge · 2025-09-29T16:28:54Z

Webrevs

ashu-mehra · 2025-09-29T18:41:21Z

@adinn @vnkozlov can you please review this.

vnkozlov

How you insure that the order of adapters generation is the same in assembly and production runs?

ashu-mehra · 2025-09-30T16:35:01Z

How you insure that the order of adapters generation is the same in assembly and production runs?

Adapters are not generated again in the production run. The adapter id is part of the AdapterHandlerEntry and they are stored in the AOTCache in the assembly run. In the production run when they are loaded back, we get the max id and use it populate the running id counter. Any new adapter generated in the production run gets the next id. Does that help?

vnkozlov · 2025-09-30T16:41:16Z

Adapters are not generated again in the production run. The adapter id is part of the AdapterHandlerEntry and they are stored in the AOTCache in the assembly run. In the production run when they are loaded back, we get the max id and use it populate the running id counter. Any new adapter generated in the production run gets the next id. Does that help?

Do we have guarantee that we load AOT adapters before any new adapter is generated?

Also if hash is not used we don't need related methods. Right?

ashu-mehra · 2025-09-30T17:00:05Z

Do we have guarantee that we load AOT adapters before any new adapter is generated?

There is no check for that as such. The adapters are loaded in AdapterHandlerLibrary::initialize() and I think there is already an assumption that AdapterHandlerLibrary::initialize() would be called before any adapters are created. I can add an assert that id_counter is 0 in AdapterHandlerLibrary::initialize() to make it more explicit. Would that be sufficient?

Also if hash is not used we don't need related methods. Right?

Hash is still needed to look up an adapter in the runtime table based on the fingerprint obtained from method signature.

vnkozlov · 2025-09-30T18:01:01Z

I can add an assert that id_counter is 0 in AdapterHandlerLibrary::initialize() to make it more explicit. Would that be sufficient?

Yes. Adapters can't be requested when AdapterHandlerLibrary::initialize() is executed (we still running in one thread). And after AdapterHandlerLibrary::initialize() it is okay.

vnkozlov · 2025-09-30T18:03:28Z

src/hotspot/share/runtime/sharedRuntime.cpp

+    max_id = MAX2(max_id, entry->id());
  });
+  // Set adapter id to the maximum id found in the AOTCache
+  _id_counter = max_id;


Is this number the same as number of AOT adapter entries in AdapterHandlerEntry? Do we need max_id? In which case they could be different?

Is this number the same as number of AOT adapter entries in AdapterHandlerEntry? Do we need max_id? In which case they could be different?

I thought about this. It is possible that some adapters generated in assembly phase are not stored in the cache. So there may be gaps in the adapter ids of the adapters in the cache. In such case using the number of entries to decide next adapter id can result in clash of adapter id with the runtime generated adapters. But the maximum id ensures adapter ids are never reused.

Please add comment about that.

Now only assert(_id_counter ==0) is missing.

Added the assert before _id_counter = max_id

AOT stored handlers to initialize _id_counter Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

vnkozlov · 2025-09-30T22:54:48Z

src/hotspot/share/runtime/sharedRuntime.cpp

+  if (id == 0) {
+    // id_counter overflow
+    return nullptr;
+  }


I think it will cause issue with ubsan because we don't check for nullptr returned from this method.
May be use guarantee(id > 0); instead ?

2^32 -1 is big number. We can't have so much method's signatures combinations.

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

iklam

Looks good. Just a couple of nits.

iklam · 2025-10-02T18:54:57Z

src/hotspot/share/runtime/sharedRuntime.cpp

 AdapterHandlerEntry* AdapterHandlerLibrary::new_entry(AdapterFingerPrint* fingerprint) {
-  return AdapterHandlerEntry::allocate(fingerprint);
+  uint id = (uint)AtomicAccess::add((int*)&_id_counter, 1);
+  guarantee(id > 0, "id_counter overflow");


I think we can even change this to an assert. We limit the AOT metaspace size to UnscaledClassSpaceMax which is 4GB.

https://github.com/openjdk/jdk/blob/1d55adee11fc2fdbf2e009e1308b763fd7217dad/src/hotspot/share/cds/aotMetaspace.cpp#L304C24-L304C45

All AOT methods would have to live within the AOT metaspace , so we will have much fewer than 2^32 methods, which means will we have much fewer than 2^32 signatures. So the id will never overflow. Maybe change this to:

assert(id > 0, "we can never overflow because AOT cache cannot contain more than 2^32 methods");

Changed it to assert as suggested

iklam · 2025-10-02T18:56:57Z

src/hotspot/share/runtime/sharedRuntime.hpp

  static const int ENTRIES_COUNT = 4;

 private:
+  uint _id;


This can be moved near _linked so it can fit in the existing unused padding.

Good point. Done.

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

vnkozlov

Good.

iklam

LGTM

ashu-mehra · 2025-10-02T21:06:30Z

@iklam @vnkozlov thanks for the review

ashu-mehra · 2025-10-03T02:41:31Z

/integrate

openjdk · 2025-10-03T02:43:18Z

Going to push as commit f62b9ec.
Since your change was applied there have been 121 commits pushed to the master branch:

854b384: 8304811: vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails with JVMTI_ERROR_TYPE_MISMATCH
da7121a: 8366461: Remove obsolete method handle invoke logic
fa6e884: 8298823: [macos] java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with "No MouseReleased event on label!"
... and 118 more: https://git.openjdk.org/jdk/compare/5d93242028dfc68b838a8efb0fbc4de3fea7fa0d...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-10-03T02:43:25Z

@ashu-mehra Pushed as commit f62b9ec.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache

737b908

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

openjdk bot added the hotspot hotspot-dev@openjdk.org label Sep 29, 2025

openjdk bot added the rfr Pull request is ready for review label Sep 29, 2025

vnkozlov reviewed Sep 30, 2025

View reviewed changes

ashu-mehra added 2 commits September 30, 2025 16:18

Add comment explaining the reason for using largest adapter id of the

93906b1

AOT stored handlers to initialize _id_counter Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

Add assert for _id_counter == 0

84edc05

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

vnkozlov reviewed Sep 30, 2025

View reviewed changes

Replace overflow check if guarantee statement

46bda6b

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

iklam reviewed Oct 2, 2025

View reviewed changes

Address Ioi's comments

206148f

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

vnkozlov approved these changes Oct 2, 2025

View reviewed changes

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

iklam approved these changes Oct 2, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Oct 3, 2025

openjdk bot closed this Oct 3, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 3, 2025

8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache #27553

8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache #27553

Conversation

ashu-mehra commented Sep 29, 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 Sep 29, 2025

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Webrevs

Uh oh!

ashu-mehra commented Sep 29, 2025

Uh oh!

vnkozlov left a comment

Choose a reason for hiding this comment

Uh oh!

ashu-mehra commented Sep 30, 2025

Uh oh!

vnkozlov commented Sep 30, 2025

Uh oh!

ashu-mehra commented Sep 30, 2025

Uh oh!

vnkozlov commented Sep 30, 2025

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!

iklam 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!

vnkozlov left a comment

Choose a reason for hiding this comment

Uh oh!

iklam left a comment

Choose a reason for hiding this comment

Uh oh!

ashu-mehra commented Oct 2, 2025

Uh oh!

ashu-mehra commented Oct 3, 2025

Uh oh!

openjdk bot commented Oct 3, 2025

Uh oh!

openjdk bot commented Oct 3, 2025

Uh oh!

Uh oh!

ashu-mehra commented Sep 29, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Sep 29, 2025 •

edited

Loading

openjdk bot commented Sep 29, 2025 •

edited

Loading

mlbridge bot commented Sep 29, 2025 •

edited

Loading