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