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

[Evgeny Astigeevich]

On Tue, 18 Mar 2025 08:24:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Thank you for checking it.
>
> Other nmethod contructors don't have the same locking requirements, because the nmethod hasn't been registered with GC yet.  However, for the source nmethod, it could be concurrently patched by GC threads without codeCache_lock and only the per-nmethod CompiledICLocker locking mechanism.  So using memcpy() seems problematic here, because a byte-by-byte copy might see on partial updates from NativeCall::set_destination_mt_safe, for example.
> Also, there seems to be a critical race with GC here.  The destination nmethod isn't going to be registered with GC yet, correct?  In that case, GC may patch the source nmethod right after the copy, but before the destination copy is registered, leaving the destination copy with stale data.  This seems fatal, as I believe this breaks crucial invariants preventing call sites from referencing stale data.  @fisk, am I on the right track here?

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?

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

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