RFR: 8323724: Remove potential re-inflation from FastHashCode under LM_LIGHTWEIGHT

[Coleen Phillimore]

On Sat, 20 Apr 2024 13:38:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> There is a race when a thread that tries to install the hash code finds an inflated `ObjectMonitor`, which the deflation thread is concurrently deflating, thus causing the `FastHashCode` logic to re-inflate the `ObjectMonitor`.
> 
> This PR solves that by simply taking the ObjectMonitor pointer from the markWord and retrying without inflating, if it was deflated.
> 
> This enhancement will remove the last code path which can inflate an `ObjectMonitor` from a non java thread, which in turn will simplify the `is_lock_owned` logic and allow for stronger assertions.
> 
> Tested and passes tier1-tier5 ok.

This looks good.

>This enhancement will remove the last code path which can inflate an ObjectMonitor from a non java thread, which in turn will simplify the is_lock_owned logic and allow for stronger assertions.

Is there an RFE for this?  It looks like a good cleanup.

src/hotspot/share/runtime/synchronizer.cpp line 1083:

> 1081:     // NOTE: an async deflation can race after we get the monitor and
> 1082:     // before we can update the ObjectMonitor's header with the hash
> 1083:     // value below.

This is subtle.  The inflate logic will create a new inflated monitor, if the current one is being async deflated, but we can install the hash in that monitor (without it going away? It needs a handshake to go away so no.) and the logic below this comment will handle the async deflation race, which you have even if you call inflate.  Did I get this right?  Rereading the comment implies this is handled below, and in fact it is.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18876#pullrequestreview-2020357371
PR Comment: https://git.openjdk.org/jdk/pull/18876#issuecomment-2075350349
PR Review Comment: https://git.openjdk.org/jdk/pull/18876#discussion_r1578179572