Integrated: 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

This pull request has now been integrated.

Changeset: f8b0ff26
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8b0ff26c9e6643e96f06c18c509ddaf50326205
Stats:     270 lines in 10 files changed: 48 ins; 61 del; 161 mod

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

Reviewed-by: mdoerr, wkemper

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

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