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

[Erik Österlund]

On Wed, 2 Oct 2024 10:38:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

> lock/unlock has roach motel semantics: ldar/stlr are enough for that. Can you please explain why you think it doesn't?

As I said at the end of my message: "And now I'm talking about shared semantics we can assume, ignore what ldar/stlr guarantee on top of acquire/release on AArch64."

The main question isn't if ldar/stlr on AArch64 is enough but rather what shared semantics we can bet on working so we know what code is guaranteed to work vs what is not guaranteed to work.

It sounds like you are arguing that the shared semantics *should* be SC, not acquire/release. But notably without any std::atomic_thread_fence(std::memory_order_seq_cst). Not entirely sure how to interpret that. Presumably modelling locking and unlocking as some sort of accesses with total order. Yet if the involved accesses in taking the lock were SC, we wouldn't be here either.

Similar to @nick-arm I'm also reading Hans' insights as "you should have fence() in pthread_mutex_lock()". I recall Dave Dice telling me the same thing about a decade ago. In particular, he told me to expect code to break if you don't, regardless of how you choose to interpret the spec.

My main point really is that lots of code has been written assuming that there's a fence() when locking. We can choose to interpret the rather vague spec in various ways depending on what we personally think is the "right" interpretation. But the fact is that code already written is bound to be broken if we decide the "right" interpretation doesn't have a fence(), because that simply wasn't the common wisdom of the past. It's like saying we should use seq_cst instead of conservative memory ordering everywhere because newer specs define it very well. That might be a good idea in general, but we can't just remove the current fencing and expect things to work without analyzing what breaks very carefully.

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

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