On Tue, 22 Sep 2026 06:54:58 GMT, Fei Yang <[email protected]> wrote:
> This reminds me of the two narrow-CAS helpers:
> `MacroAssembler::cmpxchg_narrow_value` and `
> MacroAssembler::weak_cmpxchg_narrow_value`. With this change, I think there
> will be a `StoreLoad` ordering hole with `UseZalasr && UseZacas &&
> !UseZabha`. This PR removes the trailing `StoreLoad` fence from volatile
> stores, relying on RCsc ordering between s*.rl and subsequent acquiring
> accesses. However, the initial plain `lw` in the narrow-CAS helpers can
> observe a mismatch and return without executing `amocas.aq`.
>
> The retained `fence rw,w` before CAS and `fence r,rw` afterward do not order
> a preceding volatile store before that `lw`. For example, initially x = y =
> 0, with all accesses using volatile semantics and byte y in a separate word:
>
> ```
> Thread 0 Thread 1
> x = 1; y = 1;
> r0 = compareAndExchange(y, 1, 2); r1 = x;
> ```
>
> This permits r0 == 0 && r1 == 0, which Java forbids. Could we use `lw_aq`
> instead when `UseZalasr && acquire == Assembler::aq` for both initial loads?
> That supplies the missing RCsc acquire endpoint even on immediate failure.
Thanks for the review.
You are right: the initial word pre-check can branch directly to the failure
path when the target byte/short differs from the expected value, bypassing the
acquiring amocas. The surrounding release/acquire fences do not provide the
missing StoreLoad edge.
I updated both cmpxchg_narrow_value() and weak_cmpxchg_narrow_value() to use
lw_aq when Zalasr is enabled and acquire semantics are requested:
if (UseZalasr && ((acquire & Assembler::aq) != 0)) {
lw_aq(result, aligned_addr);
} else {
lw(result, aligned_addr);
}
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32309#issuecomment-5772877114
