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). 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 Yes, WAITER.getVolatile should work as its functionality identical to getAcquire; but before I test I would point out that this (as did getAcquire) changes the LDR to LADR even when we have CASAL (+UseLSE), so some performance impact. Whereas for a little more plumbing overhead we can avoid this performance impact in the +UseLSE case by using intrinsics. For testing, I've written a small micro benchmark as I couldn't find an existing micro benchmark that tested the xfer functionality. Is there a better test that I might have missed? Understood, I'll forgo the intrinsic approach and simply switch to using getVolatile(). Are there specific [micro]benchmarks that you would like to see the results from; what is the minimum set of OS/Architecture combinations that will satisfy reviewers? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31465#issuecomment-4720129527 PR Comment: https://git.openjdk.org/jdk/pull/31465#issuecomment-4721533159 PR Comment: https://git.openjdk.org/jdk/pull/31465#issuecomment-4744630975
