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

Wed Jun 11 19:30:28 UTC 2025

On Wed, 11 Jun 2025 08:15:52 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> While the new ChangeReason JVMCI enum looks nice, I don't quite get how/where it is (or should be) used? It seems disconnected from the `InstalledCode.changeReason` field.

I agree, I also have that feeling because the type of the field is not the enum. I'll refactor that. The end goal here mainly (but not only) is to be able to use this "change or invalidation reason" to reset Truffle CallTarget profiles when its installed code was evicted from the code cache because it was "cold". See this [draft PR](https://github.com/JohnTortugo/graal/pull/2/files#diff-1f5e4cd4034f7f7571d9a021272192501800c9b19a41101bc26aaaeebaf14e15) that I'm preparing for Truffle - it contains some spurious changes right now.

> In general, I don't find the name ChangeReason quite models the concept properly - wouldn't "InvalidationReason" be more accurate? "change" is a very broad concept.

I agree that "change" is broad, but is it a bad thing in this context? Shouldn't both sides of JVMCI (if they want to) be able to "monitor" any change that the other side did to an installed code? "invalidationReason" may not be great as well because the field will be also set when the code is installed.

> I think all JVMCI Java level tracking of change (or invalidation) reasons should be confined to HotSpotNmethod as it doesn't make much sense in the other InstalledCode (sub)classes.

IMHO it seemed right to add the field in the "InstalledCode" class because having a simple way to communicate back-and-forth that a change occurred, and why it occurred, felt like a good thing to have overall. I understand that not all users of JVMCI may use it. If you feel strongly about this I can move the field to HotSpotNmethod.

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

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