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

[Dean Long]

On Mon, 24 Mar 2025 17:25:39 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>>> 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?

If the only issue was GC updating oops concurrently, we could try using CompiledICLocker instead of forcing a safepoint.  But now that I think about it, there are other issues, like the state of the entry barrier, and other GC epoch counters, and copying those consistently may require a safepoint and/or additional GC fixup logic.  I think we need a GC expert to weigh in here.  There may be other issues we are missing.

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

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