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

[Fei Yang]

On Wed, 28 Jan 2026 22:41:43 GMT, William Kemper <wkemper 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
>
> Marked as reviewed by wkemper (Reviewer).

> Thanks @earthling-amzn!
> 
> @RealFYang, @TheRealMDoerr -- you might want to run RISC-V / PPC tests on this PR? I am pretty sure the move did not break anything. A simple `make test TEST=hotspot_gc_shenandoah` would do for testing.

Thanks for the ping. `hotspot_gc_shenandoah` test is good with fastdebug build on linux-riscv64.

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

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