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

[Cesar Soares Lucas]

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.

> 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](https://github.com/JohnTortugo/graal/pull/2/files#diff-1f5e4cd4034f7f7571d9a021272192501800c9b19a41101bc26aaaeebaf14e15R189). 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.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2964471872