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.

[~fisk] I don't think that pthread_mutex_lock been relaxed by the implementation, it's how things have always been: lock is an acquiring operation, and unlock is a releasing one. As long as there are no data races, the program is sequentially consistent. That's the same as Java synchronized blocks, and it's the same as C++ mutexes.

AArch64 memory ordering semantics are not quite as simple as acquire and release. For example, ldar and stlr are sufficient to provide fully-sequentially-consistent ordering. There's also the barrier-ordered-before guarantee.

As a rough but not formally correct approximation, 
stlr is release;store
ldar is storeLoad;load;acquire

I think the HotSpot code was assuming that the lock acquire was a full fence.

> If accesses can move out of a critical section then it completely breaks locking! Locking is supposed to provide roach-motel semantics: you can move in but never out.

It does. What it doesn't do is a full two-way barrier.

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

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