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

[Andrew Haley]

On Mon, 4 Dec 2023 07:22:21 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2630:
>> 
>>> 2628:     mv(tmp, oldv);
>>> 2629:     atomic_cas(tmp, newv, addr, Assembler::int64, Assembler::aq, Assembler::rl);
>>> 2630:     beq(tmp, oldv, succeed);
>> 
>> The Zacas spec says: `The memory operation performed by an AMOCAS.W/D/Q, when not successful, has acquire semantics if aq bit is 1 but does not have release semantics, regardless of rl.`
>> 
>> So when the CAS fails, I think we are lacking the needed semantics which is enforced at L2645 for the else block. Seems that we should place a `membar(AnyAny);` after the `beq` instruction when  like our aarch64 counterpart [1].
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L2758
>
> Good! Yea, we discussed that internally and I thought we fixed that, those changes seems to have been lost, thanks!

That `dmb` is not present in the AArch64 port because we want a release when the CAS fails, because if it fails nothing was stored, so there is literally nothing for a subsequent load from that address to synchronize with.

It's there because of this re-ordering:



	<Access [A]>

	// atomic_op (B)
1:	ldaxr	x0, [B]		// Exclusive load with acquire
	<op(B)>
	stlxr	w1, x0, [B]	// Exclusive store with release
	cbnz	w1, 1b

	<Access [C]>

It doesn't forbid orderings such as

Load [B] -> Load [C] -> Store [A] -> Store [B]


[See here](https://mail.openjdk.org/pipermail/aarch64-port-dev/2014-February/000706.html)

The Arm memory model has been strengthened, and this reasoning looks a bit shaky today. At the time we did not know if any of the usages of `cmpxchgptr`required "full barrier" semantics, so we put a full barrier in for safety's sake.

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

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