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

[Aleksey Shipilev]

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

All right, thanks for testing! I am willing to integrate this soon, so I am looking for more formal Reviews at this point.

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

PR Comment: https://git.openjdk.org/jdk/pull/29444#issuecomment-3818202381