8359064: Expose reason for marking nmethod non-entrant to JVMCI client

[JohnTortugo]

We recently introduced a way to set the reason why a nmethod was being marked as not entrant, see here and here.

This PR is to expose in the JVMCI interface the reason why the nmethod was flagged as not entrant. This will allow JVMCI-based compilers to implement heuristics to handle re-compilations differently based on what happened to earlier versions of a method, for instance, this will likely be used to address this RFE in Truffle.

Tested on Linux x86_64, ARM with JTREG tier 1-3.

---

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-8359064: Expose reason for marking nmethod non-entrant to JVMCI client (Enhancement - P4)

Reviewers

• Doug Simon (@dougxc - Reviewer)
• Tom Rodriguez (@tkrodriguez - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25706

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back cslucas! 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]

@JohnTortugo 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:

8359064: Expose reason for marking nmethod non-entrant to JVMCI client

Reviewed-by: dnsimon, never

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 154 new commits pushed to the master branch:

• c4fb00a: 8358769: Update --release 25 symbol information for JDK 25 build 26
• 01d4b77: 8319242: HotSpot Style Guide should discourage non-local variables with non-trivial initialization or destruction
• c7125aa: 8020282: Generated code quality: redundant LEAs in the chained dereferences
• ... and 151 more: https://git.openjdk.org/jdk/compare/fe3be498b83e70a9f4739ddad6642c3aa04a97d3...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]

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

• graal
• hotspot-compiler

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]

Webrevs

• 08: Full - Incremental (fcfa0730)
• 07: Full - Incremental (68271c7a)
• 06: Full - Incremental (c0e970f1)
• 05: Full - Incremental (6f6d129b)
• 04: Full - Incremental (831ba2f0)
• 03: Full - Incremental (1f3c2598)
• 02: Full - Incremental (fcf838bd)
• 01: Full - Incremental (5e4b8145)
• 00: Full (9478d1de)

[mhaessig]

Thank you for working on this. Now #25338 makes even more sense 😄

A naive question: is it possible to somehow share the enum definition in hotspot with the Java side in JVMCI? If all change reasons were enums, they would be much easier to understand.

[dougxc]

A naive question: is it possible to somehow share the enum definition in hotspot with the Java side in JVMCI? If all change reasons were enums, they would be much easier to understand.

Not directly but you can have a mirror enum in JVMCI whose ordinal and message could be kept in sync and initialized from native code. As an example, see jdk.vm.ci.hotspot.HotSpotCompiledCodeStream.Tag.

[JohnTortugo]

Thank you for the comments. I added the comments that you asked @dougxc and I did some refactoring around the definition of the ChangeReason enum in the JVMCI API.

[dougxc]

While the new ChangeReason JVMCI enum looks nice, I don't quite get how/where it is (or should be) used? It seems disconnected from the InstalledCode.changeReason field.

[dougxc]

In general, I don't find the name ChangeReason quite models the concept properly - wouldn't "InvalidationReason" be more accurate? "change" is a very broad concept.

[dougxc]

I think all JVMCI Java level tracking of change (or invalidation) reasons should be confined to HotSpotNmethod as it doesn't make much sense in the other InstalledCode (sub)classes.

[JohnTortugo]

While the new ChangeReason JVMCI enum looks nice, I don't quite get how/where it is (or should be) used? It seems disconnected from the InstalledCode.changeReason field.

I agree, I also have that feeling because the type of the field is not the enum. I'll refactor that. The end goal here mainly (but not only) is to be able to use this "change or invalidation reason" to reset Truffle CallTarget profiles when its installed code was evicted from the code cache because it was "cold". See this draft PR that I'm preparing for Truffle - it contains some spurious changes right now.

In general, I don't find the name ChangeReason quite models the concept properly - wouldn't "InvalidationReason" be more accurate? "change" is a very broad concept.

I agree that "change" is broad, but is it a bad thing in this context? Shouldn't both sides of JVMCI (if they want to) be able to "monitor" any change that the other side did to an installed code? "invalidationReason" may not be great as well because the field will be also set when the code is installed.

I think all JVMCI Java level tracking of change (or invalidation) reasons should be confined to HotSpotNmethod as it doesn't make much sense in the other InstalledCode (sub)classes.

IMHO it seemed right to add the field in the "InstalledCode" class because having a simple way to communicate back-and-forth that a change occurred, and why it occurred, felt like a good thing to have overall. I understand that not all users of JVMCI may use it. If you feel strongly about this I can move the field to HotSpotNmethod.

[dougxc]

I agree that "change" is broad, but is it a bad thing in this context? Shouldn't both sides of JVMCI (if they want to) be able to "monitor" any change that the other side did to an installed code? "invalidationReason" may not be great as well because the field will be also set when the code is installed.

The only change we're talking about is invalidation via nmethod::make_not_entrant right? If so, then it really is only an invalidation reason.

Why will the field be set when the code is installed? Do you mean it will be initialized to the default int value of 0? Then it should be initialized to -1 to denote that no invalidation has occurred.

All the current reasons are HotSpot specific and the very notion of "change" is exactly tied to nmethod::make_not_entrant so I still think this should all be confined to HotSpotNmethod until we have a good use case for lifting it up to InstalledCode. We've learnt through painful experience that making API too broad, too early almost always comes back to bite us. I would also drop the enum on the Java side. It really doesn't add any extra value as shown by installedCode.getChangeReason() == HotSpotNmethod.ChangeReason.GC_UNLINKING_COLD.ordinal() here. That is, if you're using the ordinal of an enum, then the enum is probably just an unnecessary box for an int. While you could make the HotSpotNmethod.invalidationReason field itself be an enum, that makes setting the field in JVMCINMethodData::invalidate_nmethod_mirror significantly more complicated.

[JohnTortugo]

The only change we're talking about is invalidation via nmethod::make_not_entrant right? If so, then it really is only an invalidation reason.
Why will the field be set when the code is installed? Do you mean it will be initialized to the default int value of 0? Then it should be initialized to -1 to denote that no invalidation has occurred.

I was referring to the change made in jvmciEnv.cpp in this PR.

All the current reasons are HotSpot specific and the very notion of "change" is exactly tied to nmethod::make_not_entrant so I still think this should all be confined to HotSpotNmethod until we have a good use case for lifting it up to InstalledCode. We've learnt through painful experience that making API too broad, too early almost always comes back to bite us. I would also drop the enum on the Java side. It really doesn't add any extra value as shown by installedCode.getChangeReason() == HotSpotNmethod.ChangeReason.GC_UNLINKING_COLD.ordinal() here. That is, if you're using the ordinal of an enum, then the enum is probably just an unnecessary box for an int. While you could make the HotSpotNmethod.invalidationReason field itself be an enum, that makes setting the field in JVMCINMethodData::invalidate_nmethod_mirror significantly more complicated.

Sounds good to me. I'll rename the field to invalidatedReason, move it to HotSpotNmethod and remove the enum from Java side.

[JohnTortugo]

@tkrodriguez , @dougxc - are you OK with the latest changes I pushed?

[dougxc]

@tkrodriguez , @dougxc - are you OK with the latest changes I pushed?

Modulo the comment I just made, these changes now look good.

[tkrodriguez]

Module my comments about the enum it looks good to me.

[JohnTortugo]

/integrate

[openjdk]

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

• 2e3bdec: 8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled
• c4fb00a: 8358769: Update --release 25 symbol information for JDK 25 build 26
• 01d4b77: 8319242: HotSpot Style Guide should discourage non-local variables with non-trivial initialization or destruction
• ... and 152 more: https://git.openjdk.org/jdk/compare/fe3be498b83e70a9f4739ddad6642c3aa04a97d3...master

Your commit was automatically rebased without conflicts.

[openjdk]

@JohnTortugo Pushed as commit 2fe1298.

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

[dholmes-ora]

@JohnTortugo the new test is failing in our CI - please see https://bugs.openjdk.org/browse/JDK-8360049

[dougxc]

@JohnTortugo the new test is failing in our CI - please see https://bugs.openjdk.org/browse/JDK-8360049

It is being fixed by #25911. This is my fault for not having run the internal CI on this change before approving.

[JohnTortugo]

/backport jdk21u-dev

[openjdk]

@JohnTortugo Could not automatically backport 2fe12984 to openjdk/jdk21u-dev due to conflicts in the following files:

• src/hotspot/share/c1/c1_Runtime1.cpp
• src/hotspot/share/ci/ciReplay.cpp
• src/hotspot/share/code/codeCache.cpp
• src/hotspot/share/code/nmethod.cpp
• src/hotspot/share/code/nmethod.hpp
• src/hotspot/share/compiler/compilationPolicy.cpp
• src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
• src/hotspot/share/jvmci/jvmciEnv.cpp
• src/hotspot/share/jvmci/jvmciEnv.hpp
• src/hotspot/share/jvmci/jvmciRuntime.cpp
• src/hotspot/share/jvmci/vmStructs_jvmci.cpp
• src/hotspot/share/oops/instanceKlass.cpp
• src/hotspot/share/oops/method.cpp
• src/hotspot/share/prims/whitebox.cpp
• src/hotspot/share/runtime/deoptimization.cpp
• src/hotspot/share/runtime/javaThread.cpp
• test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleCodeInstallationTest.java
• test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/TestHotSpotVMConfig.java

Please fetch the appropriate branch/commit and manually resolve these conflicts by using the following commands in your personal fork of openjdk/jdk21u-dev. Note: these commands are just some suggestions and you can use other equivalent commands you know.

# Fetch the up-to-date version of the target branch
$ git fetch --no-tags https://git.openjdk.org/jdk21u-dev.git master:master

# Check out the target branch and create your own branch to backport
$ git checkout master
$ git checkout -b backport-JohnTortugo-2fe12984-master

# Fetch the commit you want to backport
$ git fetch --no-tags https://git.openjdk.org/jdk.git 2fe12984474656a08c4525c04a351d85be73f658

# Backport the commit
$ git cherry-pick --no-commit 2fe12984474656a08c4525c04a351d85be73f658
# Resolve conflicts now

# Commit the files you have modified
$ git add files/with/resolved/conflicts
$ git commit -m 'Backport 2fe12984474656a08c4525c04a351d85be73f658'

Once you have resolved the conflicts as explained above continue with creating a pull request towards the openjdk/jdk21u-dev with the title Backport 2fe12984474656a08c4525c04a351d85be73f658.

Below you can find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 2fe12984 from the openjdk/jdk repository.

The commit being backported was authored by Cesar Soares Lucas on 19 Jun 2025 and was reviewed by Doug Simon and Tom Rodriguez.

Thanks!

[JohnTortugo]

/backport jdk25u-dev

[openjdk]

@JohnTortugo The target repository jdk25u-dev is not a valid target for backports.
List of valid target repositories: openjdk/jdk, openjdk/jdk11u, openjdk/jdk11u-dev, openjdk/jdk17u, openjdk/jdk17u-dev, openjdk/jdk21u, openjdk/jdk21u-dev, openjdk/jdk25u, openjdk/jdk8u, openjdk/jdk8u-dev, openjdk/jfx, openjdk/jfx17u, openjdk/jfx21u, openjdk/jfx25u, openjdk/lilliput-jdk17u, openjdk/lilliput-jdk21u, openjdk/lilliput-jdk25u, openjdk/shenandoah-jdk21u, openjdk/shenandoah-jdk8u.
Supplying the organization/group prefix is optional.

[JohnTortugo]

/backport jdk25u

[openjdk]

@JohnTortugo the backport was successfully created on the branch backport-JohnTortugo-2fe12984-master in my personal fork of openjdk/jdk25u. To create a pull request with this backport targeting openjdk/jdk25u:master, just click the following link:

➡️ Create pull request

The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 2fe12984 from the openjdk/jdk repository.

The commit being backported was authored by Cesar Soares Lucas on 19 Jun 2025 and was reviewed by Doug Simon and Tom Rodriguez.

Thanks!

If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk25u:

$ git fetch https://github.com/openjdk-bots/jdk25u.git backport-JohnTortugo-2fe12984-master:backport-JohnTortugo-2fe12984-master
$ git checkout backport-JohnTortugo-2fe12984-master
# make changes
$ git add paths/to/changed/files
$ git commit --message 'Describe additional changes made'
$ git push https://github.com/openjdk-bots/jdk25u.git backport-JohnTortugo-2fe12984-master