On Thu, 2 Jul 2026 16:31:03 GMT, Gui Cao <[email protected]> wrote: >> Hi, Maybe the cause of this issue is that these Java calls generate a >> C2AccessFence, which creates MemBarRelease and MemBarAcquire operations >> before and after CompareAndExchangeX. However, the C2’s >> `unnecessary_membar_acquire` and `unnecessary_membar_release` are >> unconditionally removed by calling `is_CAS(load_store->Opcode(), true);` , >> which unconditionally removes the preceding and following MEMBAR operations. >> This works fine when UseLSE is enabled, but when UseLSE is disabled, the >> program experiences a pseudo-deadlock. > >> Hi, Maybe the cause of this issue is that these Java calls generate a >> C2AccessFence, which creates MemBarRelease and MemBarAcquire operations >> before and after CompareAndExchangeX. However, the C2’s >> `unnecessary_membar_acquire` and `unnecessary_membar_release` are >> unconditionally removed by calling `is_CAS(load_store->Opcode(), true);` , >> which unconditionally removes the preceding and following MEMBAR operations. >> This works fine when UseLSE is enabled, but when UseLSE is disabled, the >> program experiences a pseudo-deadlock. > > Sorry, I didn't quite follow the detailed discussion here just now. If we > just make some changes, will that completely fix issues like this?
@zifeihan The reason we remove the memory barrier is that we assume the accompanying memory access imposes such memory barrier already. This is correct, the emitted code semantically has an acquire barrier before the CAS sequence and a release barrier after the CAS sequence. The issue here is that a later load is reordered into the CAS sequence, which means it floats up past the trailing release barrier (this is legal), but it is still below the leading acquire barrier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31465#issuecomment-4868518513
