RFR: 8319773: Avoid inflating monitors when installing hash codes for LM_LIGHTWEIGHT [v9]

[Daniel D. Daugherty]

On Tue, 21 Nov 2023 14:37:01 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> LM_LIGHTWEIGHT only uses the lock bits for its locking. This leaves the hashCode bits free when a monitor is not inflated. So instead of inflating when installing the hashCode on a fast locked object it can simply use the hashCode bits in the markWord.
>> 
>> The mark word transitions Unlocked (0b01) <=> Locked (0b00) are done by retrying the CAS if it fails due to non-lock bit changes. 
>> The mark word transitions Monitor (0b10) <=> Locked/Unlocked (0b0X) are the same as before, inflation already handles hash codes. This change does not interact with the mark word if it is in a Monitor (0b10) state, so the strong CAS which is used for deflation are still valid, and will not fail to any other reason than the cooperative race to help transition the mark word during deflation.
>> 
>> This is dependent on JDK-8319778 simply because JDK-8319797 is dependent on both this and JDK-8319778.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/pr/16602' into JDK-8319773
>  - Fix copy paste typo.
>  - Update src/hotspot/share/opto/library_call.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Add retry CAS comment
>  - Use is_neutral over is_unlocked
>  - Merge remote-tracking branch 'upstream_jdk/pr/16602' into JDK-8319773
>  - Use more familiar CAS variable names and pattern
>  - Move is_lock_owned closer to its only use
>  - Merge remote-tracking branch 'upstream_jdk/pr/16602' into JDK-8319773
>  - Simplify test.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/87ee59dd...b4061417

I've re-reviewed the changes from v03 -> v08.

Thumbs up with what you currently have. There's still one open query
in `FastHashCode` about whether the VMThread can get in there
during JVM/TI tagging... It may be best to file a follow up bug for
chasing down that detail and possibly addressing it... Or you could
address it with one more change in this PR...

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16603#pullrequestreview-1755946248