RFR: 8376472: Shenandoah: Assembler store barriers read destination memory despite the decorators [v2]
Martin Doerr
mdoerr at openjdk.org
Fri Jan 30 10:23:01 UTC 2026
On Fri, 30 Jan 2026 10:10:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> 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.
Looks correct. Thanks! Isn't it better to avoid having `BarrierSetAssembler::store_at` twice? I liked that in the old code. I leave you free to decide.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29444#discussion_r2745581668
More information about the hotspot-dev
mailing list