RFR: 8359064: Expose reason for marking nmethod non-entrant to JVMCI client [v2]

[Doug Simon]

On Wed, 11 Jun 2025 00:05:47 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> We recently introduced a way to set the reason why a nmethod was being marked as `not entrant`, see [here](https://github.com/openjdk/jdk/pull/23980) and [here](https://github.com/openjdk/jdk/pull/25338).
>> 
>> 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](https://github.com/oracle/graal/issues/11045
>> ). 
>> 
>> Tested on Linux x86_64, ARM with JTREG tier 1-3.
>
> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback: add comments, refactor enum definition in the Java side.

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.

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

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2961675374
PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2961676448
PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2961682020