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

[Tom Rodriguez]

On Thu, 12 Jun 2025 20:18:10 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:
> 
>   Fix some remaining renames.

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.

src/hotspot/share/code/nmethod.cpp line 2125:

> 2123:   JVMCINMethodData* nmethod_data = jvmci_nmethod_data();
> 2124:   if (nmethod_data != nullptr) {
> 2125:     nmethod_data->invalidate_nmethod_mirror(this, is_cold() ? nmethod::InvalidationReason::GC_UNLINKING_COLD : nmethod::InvalidationReason::GC_UNLINKING);

So then this is the heart of what you're after?  Maybe `GC_UNLINKING_COLD` should be `COLD_UNLOADING`?  GC is doing it but it's not for GC reasons.  `GC_UNLINKING` might better be `GC_UNLOADING`.  I don't think the `nmethod::unlink` name is a good one to propagate into enum names.

`is_cold` isn't completely reliable here as an method could both have dead oops and be cold.  I guess that probably doesn't matter though.

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

PR Comment: https://git.openjdk.org/jdk/pull/25706#issuecomment-2971527074
PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2146005973