RFR: 8325937: runtime/handshake/HandshakeDirectTest.java causes "monitor end should be strictly below the frame pointer" assertion failure on AArch64

[Andrew Haley]

On Tue, 1 Oct 2024 18:38:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Add missing StoreLoad fences in handshaking code to match safepoint code.  Thanks to @pchilano for finding this bug.
> 
> Tested with tier1-4 and tier8 which has Kitchensink in it.

On 10/2/24 10:59, Nick Gasson wrote:
>> No. "sequentially consistent" doesn't imply that every synchronizes-with operation is a full fence. It just means that if you
> do a bunch of writes in Thread A, then a releasing operation in A, then an acquiring operation in Thread B, then read in B whatever you just wrote in A, the program behaves as though there were the same total order observed by all threads.
> 
> This is DRF-SC though, right?

Absolutely. Unless a program is DRF, all bets are off.

> In the absence of data races you get SC behaviour. But the code here has a racy read of a variable without holding the mutex.
Note that I didn't mention mutexes at all.

You don't have to still be holding the mutex, you only have to be synchronized
with a happens-before and happens-after operation. The problem here, assuming
it has been correctly diagnosed, is that the access is indeed racy, which is UB.
The bug is in the program, not in libc, C++, or the CPU hardware.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21295#issuecomment-2388228424