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

[Tom Rodriguez]

On Sun, 15 Jun 2025 00:57:55 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciRuntime.cpp line 818:
>> 
>>> 816:       HotSpotJVMCI::InstalledCode::set_address(jvmciEnv, nmethod_mirror, 0);
>>> 817:       HotSpotJVMCI::InstalledCode::set_entryPoint(jvmciEnv, nmethod_mirror, 0);
>>> 818:       HotSpotJVMCI::HotSpotNmethod::set_invalidationReason(jvmciEnv, nmethod_mirror, static_cast<int>(invalidation_reason));
>> 
>> I think you're in danger of overwriting the invalidationReason here.  `invalidate_nmethod_mirror` can be called for unloaded nmethods after they have been made not entrant.
>
> I see, thank you for the catch! I'm not sure how I can detect this case. My first idea was to just check if the "invalidationReason" field is already set or not, but looks like in order to do that I'd need to wrap the `nmethod_mirror` in a `JVMCIObject`. Unfortunately, there is a comment just a few lines above this change saying to _not_ do this wrapping. I'm not quite familiar with all nmethod state transitions. Would it be sufficient to just add a check for whether the nmethod is already non-entrant on line 818?

You should be able to use `HotSpotJVMCI::HotSpotNmethod::get_invalidationReason`.  JVMCIObject handles dispatching if you don't know which runtime you are attached to but we know we are talking to HotSpot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25706#discussion_r2150464134