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

[Cesar Soares Lucas]

On Fri, 13 Jun 2025 18:57:43 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.
>
> This seems like a very complicated way for Truffle to tell itself that it invalidated some installed code.  Couldn't this be done with bookkeeping purely on the Truffle side?  A weak map of InstalledCode instances that were invalidated because they were cold would be completely sufficient, wouldn't it?

Thank you for commenting @tkrodriguez .

> This seems like a very complicated way for Truffle to tell itself that it invalidated some installed code. 

If by "it" you mean Truffle then the answer is no. The main point of this change is to communicate to Truffle when something in the HotSpot side invalidated the code, _in particular_ [I'm interested](https://github.com/oracle/graal/issues/11045) in the situation when the heuristics that monitor the code cache caused the eviction of a nmethod because it considered it _cold_. Truffle itself uses a different concept of hot/cold method...

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

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