RFR: 8341854: Incorrect clearing of ZF in fast_unlock_lightweight on x86

Fredrik Bredberg fbredberg at openjdk.org
Wed Oct 9 13:42:12 UTC 2024


This bug was created in [JDK-8320318](https://bugs.openjdk.org/browse/JDK-8320318).

`C2_MacroAssembler::fast_unlock_lightweight()` on x86 issues a `testl(monitor, monitor);` instruction for the sole purpose of clearing the zero-flag, which should force us to go into the slow path.

However, this instruction incorrectly only checks the lower 32-bits, which results in setting the zero-flag if the ObjectMonitor has all-zeros in the lower 32-bits. For some reason this seems to be quite common on macosx-x64, where we tend to get an ObjectMonitor address that is 0x0000600000000000.

The reason we wanted to go into the slow path was that we've observed that there is a thread queued on either the EntryList or cxq, and there is no successor. However since we failed to clear the zero-flag, we will go into the fast path and no one will wake up the stranded thread. Thus the system will hang and any test system will timeout.

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

Commit messages:
 - 8341854: Incorrect clearing of ZF in fast_unlock_lightweight on x86

Changes: https://git.openjdk.org/jdk/pull/21422/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21422&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341854
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21422/head:pull/21422

PR: https://git.openjdk.org/jdk/pull/21422


More information about the hotspot-compiler-dev mailing list