On Wed, 10 Jun 2026 17:35:43 GMT, Mat Carter <[email protected]> wrote:
> With -UseLSE the Starvation test on Windows ARM64 timeouts close to 100% > whereas this only happens on Linux ARM64 on larger machines with many cores. > The issue is that C2 outputs an LDR following the CAS in LinkedTransferQueue > which can execute before the STLXR breaking the Dekker protocol. > > Replacing the LDR with LADR by using getAcquire solves the issue as it won't > be reordered before the STLXR. This does impact the +UseLSE case as the LADR > was not necessary and is slightly more expensive than LDR. But to handle > this case would require larger changes to Hotspot > > Starvation test passes on Windows ARM64 and Linux ARM64, with no regressions > on tier1 > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31465#issuecomment-4867691121
