On Tue, 16 Jun 2026 14:54:03 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). > > So I have a better solution that I'm experimenting with but its very specific > to LinkedTransferQueue, so that it doesn't impact other CAS operations where > there's no subsequent read. > > Ideally there would be a way to identify the LDR is part of the dekker > protocol, but that seems to reache far and wide into HotSpot, so instead of > changing the LDR to LDAR, I am proposing we add a 'sync' point before the LDR > > In the xfer and tryMatchData we call an intrinsic (lets call it dekkerFence) > prior to reading the waiter. C2 makes this a no-op on architectures that > already have full ordering (x86 and ARM64 +UseLSE). On ARM64 -useLSE, C2 > generates either of the following for dekkerFence: > > 1) DMB ISH > 2) LDAR xzr, [sp] > > So the ordering becomes: > > STLXR[item] > dekkerFence > LDR[waiter] > > From what I'm reading the second option still prevents the LDR floating above > the STLXR while still allowing the core to run non-related operations out of > order. Whereas the DMB ISH will stall all operations. > > I'll proceed with testing but will wait to hear if other sites have been > identified @macarte I believe a volatile load would suffice, can you try that approach? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31465#issuecomment-4720975428
