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]

Thank you for commenting @tkrodriguez .

This seems like a very complicated way for Truffle to tell itself that it invalidated some installed code.

If by "it" you mean Truffle then the answer is no. The main point of this change is to communicate to Truffle when something in the HotSpot side invalidated the code, in particular I'm interested in the situation when the heuristics that monitor the code cache caused the eviction of a nmethod because it considered it cold. Truffle itself uses a different concept of hot/cold method...

[tkrodriguez]

Sorry for the confusion on my part. The lack of a PR that's consuming these changes makes it harder to know which parts are the important ones.

[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