RFR: 8299614: Shenandoah: STW mark should keep nmethod/oops referenced from stack chunk alive [v2]

William Kemper wkemper at openjdk.org
Mon Sep 11 22:11:38 UTC 2023


On Mon, 11 Sep 2023 21:50:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the investigation in the bug. Basically, with Loom we have to enable nmethod barriers to get the proper marking of nmethods/oops from stack chunks. See `ShenandoahMarkRefsSuperClosure::do_nmethod` callers and callees for more details. This IMO makes `ShenandoahNMethodBarrier` flag non-optional, as we have to enable nmethod barriers when Loom is enabled. The major part of PR deals with that.
>> 
>> Additional testing:
>>  - [x] Original reproducer does not fail anymore
>>  - [x] MacOS AArch64 fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 fastdebug, `hotspot_gc_shenandoah`
>>  - [ ] Linux AArch64 fastdebug, `tier1 tier2 tier3` with `-XX:+UseShenandoahGC`
>>  - [ ] Linux x86_64 fastdebug, `tier1 tier2 tier3` with `-XX:+UseShenandoahGC`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Should arm the nmethods for thread root processing

I'm not suggesting we keep `ShenandoahNMethodBarrier` flag, but for the sake of my own understanding: the passive mode does not need the nmethod barriers, correct?

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

PR Comment: https://git.openjdk.org/jdk/pull/15669#issuecomment-1714652233


More information about the hotspot-gc-dev mailing list