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

[Erik Österlund]

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.

We have two options:
1) Accept the slippery "water park" semantics where lock/unlock only has acquire/release semantics and try to retroactively fix all the bugs due having assumed the "roach hotel" semantics for many years. Many more years longer than any new fancy C++ 17 standard cooked up for new fancy C++ std::mutex (that we don't use).
2) Enforce the "roach hotel" semantics that have been assumed and engrained for years.

If we do accept that we can only rely on acquire/release semantics for mutexes, then consider the following fun situation:

store(...);
{ MutexLocker ml(...); }
x = load(...);

Are we cool with the store and load reordering across an entire critical section? If not, then that roach hotel sounds pretty cozy to me. Otherwise, good luck tracking down all the code that assumes this.
And now I'm talking about shared semantics we can assume, ignore what ldar/stlr guarantee on top of acquire/release on AArch64.

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

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