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

[Cesar Soares Lucas]

On Fri, 13 Jun 2025 19:03:54 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some remaining renames.
>
> 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?

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

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