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

Patricio Chilano Mateo pchilanomate at openjdk.org
Wed Oct 9 13:44:59 UTC 2024


On Wed, 9 Oct 2024 13:11:58 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

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

Looks good, thanks for fixing this.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21422#pullrequestreview-2357206121


More information about the hotspot-compiler-dev mailing list