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

[Tom Rodriguez]

On Mon, 2 Jun 2025 17:01:26 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> If it is moved, the [CompiledMethodUnload](https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#CompiledMethodUnload) event is sent, followed by a new CompiledMethodLoad event.

>    we now have 2 nmethods alive with the same compile_id which could be confusing.

It's nice that the JVMTI docs considered this problem but the notifications will be sent in the reverse order given our current implementation.  We will create a new nmethod while the old nmethod might still be alive, at least for the purposes of deopt.  Since this PR doesn't actually perform any relocation, I'm not sure what the plan is here.  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.

I agree that the docs are fairly clear that all of this is ok, but that doesn't mean that assumptions haven't been made about the current implementation.  We just need to make sure we do something rational and that it's possible to understand from our output what was done.

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

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