RFR: 8316694: Implement relocation of nmethod within CodeCache [v19]

[Evgeny Astigeevich]

On Tue, 3 Jun 2025 15:49:30 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> Since this PR doesn't actually perform any relocation, I'm not sure what the plan is here.

The plan is to use this functionality in [JDK-8326205](https://bugs.openjdk.org/browse/JDK-8326205)

> The most aggressive thing that could be done is to invalidate all frames which have the old nmethod on stack, but that still leaves the nmethod live for the purposes of deopt. It would probably be ok to synthesize an unload after the deopt since there should be no actual execution in those nmethods, but you will then have to suppress the one that's normally done during nmethod::unlink.

This might have negative performance impact because we will be relocating hot nmethods. IMO it's better to let calls of the original nmethod to finish. New calls will be using the copy.

It looks like the implementation does not move code in the terms of the JVMTI spec.
The JVMTI spec expects moving code to unload it from memory:
> Compiled Method Unload
> 
> Sent when a compiled method is unloaded from memory.

As we don't want to unload code from memory, we cannot send Compiled Method Unload event.

I think we can generate just Compiled Method Load event because of the note:
> Note that a single method may have multiple compiled forms, and that this event will be sent for each form.

Alternatively, we can update the JVMTI spec to say Compiled Method Load event  can be a result of code copied.

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

PR Comment: https://git.openjdk.org/jdk/pull/23573#issuecomment-2980761814