This bug was introduced by 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.
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.
- duplicates
-
JDK-8341662 vmTestbase/gc/gctests/ObjectMonitorCleanup/ObjectMonitorCleanup.java timed out
-
- Closed
-
-
-
- Closed
-
- relates to
-
JDK-8320318 ObjectMonitor Responsible thread
-
- Resolved
-
- links to
-
Commit(master)
openjdk/jdk/fcc9c8d5
-
Review(master)
openjdk/jdk/21422