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

[Evgeny Astigeevich]

On Tue, 18 Mar 2025 19:59:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi @dean-long,
>> I see two changes can be made in nmethod:
>> 1. Call sites are patched because of changes in callees.
>> 2. Oops used in nmethod are updated.
>> 
>> The first change should not be a problem if we clear all call site. It's already done in the current code by clearing inline caches of the original nmethod. As discussed, we should not clear inline caches of the original but the copy.
>> 
>> How the second change (oops) is addressed when we create a new nmethod?
>
>> How the second change (oops) is addressed when we create a new nmethod
> 
> Called from `nmethod()` constructor [nmethod::copy_values()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/nmethod.cpp#L1741) replaces handles used during compilation with oops.
> 
> Note, `new_nmethod()` holds `CodeCache_lock` and `ciEnv::register_method()` holds `Compile_lock` (and `MethodCompileQueue_lock`).

@vnkozlov @dean-long 
It looks like the only way relocation can be performed correctly only at a safepoint. GC updating oops concurrently with relocation is an issue.
The safepoint requirement will limit use cases of relocation. Relocations should not be done often and should be done in a batch. On another side, relocating at a safepoint will simplify clone code patching. We need to fix offsets in call instructions at call sites. We don't need to clear them.
What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23573#discussion_r2010629936