RFR: 8319799: Recursive lightweight locking: x86 implementation [v10]

[Axel Boldt-Christmas]

On Tue, 23 Jan 2024 14:42:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>>> Is the lock definitely never inflated due to hash code in this case now?
>> 
>> It never inflates a locked object. The hash code race that may re-inflate a monitor is with deflation. Where it tries to install a hash code on an inflated monitor, but the monitor gets deflated between the two reads of the markWord, the thread that tries to install the hash code will create a new ObjectMonitor. [JDK-8323724](https://bugs.openjdk.org/browse/JDK-8323724) RFE is created for that issue.
>
> Hmm now that I think about it can still happen that it inflates a fast locked lock. If a third thread enters at the same time.

But regardless all paths which commit to a pop also fixes the owner. So we do not need the anonymous owner fix in fast_unlock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16607#discussion_r1463386947