RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2]

[Zhengyu Gu]

On Wed, 22 Jun 2022 15:26:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Add a newline
>>  - Merge branch 'master' into 8287818-nmethod-arming
>>  - 8287818: Shenandoah: adapt nmethod arming from Loom
>>  - Merge branch 'master' into migrate_nmethod_arming_shenandoah
>>  - v0
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSetNMethod.cpp line 72:
> 
>> 70:   ShenandoahNMethod::disarm_nmethod(nm);
>> 71:   return true;
>> 72: }
> 
> Nit: missing newline.

Fixed

> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 129:
> 
>> 127: 
>> 128: void ShenandoahCodeRoots::arm_nmethods() {
>> 129:   BarrierSet::barrier_set()->barrier_set_nmethod()->arm_all_nmethods();
> 
> Question: in `ShenandoahBarrierSet::on_thread_attach`, we check `barrier_set_nmethod() != NULL`, do we need to do the same check here, or?

Only in `passive` mode, Shenandoah does not install nmethod barrier, but `passive` mode never calls `arm_nmethod()`, etc. nmethod entry barrier related methods.

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

PR: https://git.openjdk.org/jdk/pull/9048