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

[Vladimir Kozlov]

On Tue, 17 Jun 2025 15:09:24 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.
>
>> 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.

Also, as @eastig pointed, we don't use all low case class names `nmethodrelocation` anymore.

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

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