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

Vladimir Kozlov kvn at openjdk.org
Mon Mar 17 19:51:11 UTC 2025


On Mon, 17 Mar 2025 19:09:58 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

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

Thank you for checking it.

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

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


More information about the hotspot-compiler-dev mailing list