RFR: 8315856: RISC-V: Use Zacas extension for cmpxchg [v3]

[Robbin Ehn]

On Tue, 12 Dec 2023 08:31:25 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Wow, thanks for finding that history. It's very helpful for us to understand the existence of this barrier.
>
> I have seen code, do not find it anymore in code base, which use cmpxchg for Atomic::release_store_fence().
> (which is "new");
> 
> Atomic::store(_x, true);
> Atomic::store_release_fence(_one_way_barrier, true);
> bool z = Atomic::load(_z);
> 
> But it is written as:
> 
> Atomic::store(_x, true);
> Atomic::cmpxchg(_one_way_barrier, false, true);
> bool z = Atomic::load(_z);
> 
> Where load Z happens after store X. But without release the store may happens after.
> 
> As we say:
> "All of the atomic operations that imply a read-modify-write action guarantee a two-way memory barrier across that operation."
> 
> I have look over the cmpxchg uses and not releasing 'seems' okay at first glance.
> But I think before this line changes we should release on failed CAS.

Note I mention the hotspot runtime atomic here because cmpxchgptr is used to manipulate the markword which follows hotspot atomics, not Java volatiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16910#discussion_r1423644955