P4
From discussion related to PR https://github.com/openjdk/jdk/pull/21295
[~rehn] points out:
The old implementation cleary had this as it specification (before we switched to pthread):
// See orderAccess.hpp. We assume throughout the VM that mutex lock and
// try_lock do fence-lock-acquire, and that unlock does a release-unlock,
// *in that order*. If their implementations change such that these
// assumptions are violated, a whole lot of code will break.
This code is written for that documented behavior.
Hence I instead suggest to create a stricter mutex which follows the old semantics.
In the linked bug, reads of thread state for handshakes are floating up before the mutex that assumes that the handshakee thread is safe because of this assumption.
[~rehn] points out:
The old implementation cleary had this as it specification (before we switched to pthread):
// See orderAccess.hpp. We assume throughout the VM that mutex lock and
// try_lock do fence-lock-acquire, and that unlock does a release-unlock,
// *in that order*. If their implementations change such that these
// assumptions are violated, a whole lot of code will break.
This code is written for that documented behavior.
Hence I instead suggest to create a stricter mutex which follows the old semantics.
In the linked bug, reads of thread state for handshakes are floating up before the mutex that assumes that the handshakee thread is safe because of this assumption.
- relates to
-
JDK-8325937 runtime/handshake/HandshakeDirectTest.java causes "monitor end should be strictly below the frame pointer" assertion failure on AArch64
-
- Closed
-