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

[Andrew Haley]

On Thu, 3 Oct 2024 18:48:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Referring to the comment in the code above, the strange thing is that a whole lot of code isn't broken, which could just be luck.

Thanks for that.

I think there's two things going on here. Firstly, that practical hardware designs tend to be stronger than the (deliberately loose) semantics of acquire and release require. Secondly, in most cases we don't need full fences.

> We should then file an RFE to determine whether _all_ Mutex operations require an additional fence() so that the Hotspot implementation of Mutex follows it's own stronger specification, OR try to find some proof through assertions that a fence() isn't needed everywhere we take out these locks. I'm not sure that this is possible but we should do it anyway. Most of the MutexLockers that I've put in the code is to guard critical section. Maybe that's not prone to these data races.

Yes, that's right. Code in critical sections isn't racy, by definition.

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

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