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

[Andrew Haley]

On Wed, 2 Oct 2024 13:05:45 GMT, Erik Österlund <eosterlund 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.

Good point.

I'm thinking of it in a somewhat more pragmatic (?) way, which I think is in line with how HotSpot has worked hitherto. And it's this: if we ever come across a platform on which mutexes aren't sequentially consistent, we will deal with it on an ad hoc basis.

> 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.

There are ways to write sequentially consitent code without fence instructions. For example, C++ atomics (by default) work the same way as Java volatiles, and we already know that sequentially-consistent code is the result in both cases.

> 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.

I disagree. I haven't yet seen anything to suggest that the mutex was not SC. I don't think the problem was that, it was that the HotSpot author assumed that mutex_lock() was a full fence and wanted to make use of that as a hidden side effect, but. sequential consistency does _not_ require it to be one.

> 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.

All true.

My belief is similar to yours, but my cure is different: code written on the misunderstanding that acquiring a lock is a full fence should be fixed. It's hard enough to reason about concurrency in HotSpot as it is, without trying to make things work by adding more fences "just in case."

Java has been around for a long time, and hopefully will continue for a long time. It's becoming increasingly clear that the future may not be "all the world's an x86," any more than "all the world's a VAX" was true in the long term.

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

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