RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators

[Martin Doerr]

On Tue, 27 Jan 2026 10:47:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The issue is really a correctness issue, and it readily manifests in Valhalla, which sometimes does the stores with `IS_DEST_UNINITIALIZED` set. Unfortunately, Shenandoah SATB barriers ignore this attribute, and attempt to read the memory at store address. At best it crashes the VM with the "oopness" asserts, at worst it feeds "garbage" pointers into SATB machinery, which then wrecks havoc on everything else.
> 
> We need to make sure store barriers are consistently checking these attributes. Unfortunately, that would mean doing the changes in arch-specific assembler code. 
> 
> This PR makes sure the ShenandoahBarrierSetAssembler store barriers are roughly in the same shape, and that they consult `ShenandoahBarrierSet::need_*_barrier` to make the proper decisions whether to use SATB/card barriers.
> 
> `hotspot_gc_shenandoah` is enough to sanity-check this patch, but I am also running `all` tests for extra safety.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `all` + `-XX:+UseShenandoahGC`
>  - [x] Linux {PPC64, RISC-V, S390X} server fastdebug, cross-compilation

src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 613:

> 611:                                   val,
> 612:                                   tmp1, tmp2, tmp3,
> 613:                                   preservation_level);

Shouldn't there be a `return` statement? There's another `BarrierSetAssembler::store_at` below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745464876