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

[Aleksey Shipilev]

On Fri, 30 Jan 2026 09:48:45 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Missing return in PPC64 for non-reference stores
>>  - Merge branch 'master' into JDK-8376472-shenandoah-store-barriers
>>  - More polish
>>  - RISC-V version
>>  - More touchups, AArch64 version
>>  - Store barrier cleanup
>
> 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.

Oh, YES, it should short-cut on non-reference stores. Excellent spot! So it does double write of the same value. Only fine-grained memory model tests would have caught this. Fixed in new commit. I think this is the only place where I made this mistake.

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

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