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

[Chad Rakoczy]

On Sat, 15 Mar 2025 00:24:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1399:
>> 
>>> 1397: {
>>> 1398:   debug_only(NoSafepointVerifier nsv;)
>>> 1399:   assert_locked_or_safepoint(CodeCache_lock);
>> 
>> Is this lock enough to prevent GC scan it before you finish initializing it?
>
> My question is related to `_state` field value. During usual nmethod creation the `_state` is `not_installed`.
> nmethod you are coping has `in_use` state. Someone may see this state before all fields are set.
> That is why I am asking if `CodeCache_lock` prevents any other VM's threads see it.

I believe this should behave the same as creating any other nmethod. `CodeCache_lock` is the only thing the other constructors use when initializing nmethods and if this was an issue they could also encounter the same race between initialization and setting the field.

Looking through the GC code also shows they do hold `CodeCache_lock` before scans. [G1](https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp#L112), [Shenandoah](https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp#L195), [ZGC](https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/gc/z/zNMethodTable.cpp#L215)

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

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