RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v3]

Dean Long dlong at openjdk.org
Mon Aug 4 21:26:23 UTC 2025


On Fri, 1 Aug 2025 21:38:11 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix PPC64
>
> src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 84:
> 
>> 82:       nativeMovRegMem_at(new_mov_instr.buf)->set_offset(new_value, false /* no icache flush */);
>> 83:       // Swap in the new value
>> 84:       uint64_t v = Atomic::cmpxchg(instr, old_mov_instr.u64, new_mov_instr.u64, memory_order_release);
> 
> We have `OrderAccess::release()` above, so `memory_order_release` looks redundant. Shouldn't we use `memory_order_relaxed`, here?

I think you are right.  But your question about release is making me wonder if we need acquire as well.  For example if two threads are racing to disarm, is there a memory visibility problem if we do not use acquire for the CAS, or if we did the release only on a successful CAS?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26399#discussion_r2252604613


More information about the hotspot-dev mailing list