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

[Daniel D. Daugherty]

On Thu, 16 Nov 2023 18:24:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 521:
>> 
>>> 519:           const markWord new_mark = mark.set_fast_locked();
>>> 520:           const markWord old_mark = mark;
>>> 521:           mark = obj()->cas_set_mark(new_mark, old_mark);
>> 
>> I'm having trouble seeing how this change is related to hash codes.
>> The previous code did not loop and if the calling thread's attempt to
>> lightweight lock the object lost a race, then we simply fell thru down
>> to the inflate-enter loop...
>> 
>> I don't see any explanation for this change in the bug report or in the
>> PR anywhere. Perhaps I'll figure it out as I reason thru the changes...
>
> The change from `mark.is_neutral()` to `mark.is_unlocked()` is equivalent
> since both functions have the exact same meaning. Is there some reason to
> make that change? Are we trying to migrate away from `mark.is_neutral()`  to
> `mark.is_unlocked()`? I think the original "neutral" concept was from when we
> had biased locking...

The rename from `locked_mark` to `new_mark` seems superfluous. The old and
new version of the variable name are used in the same places so I don't quite see
the reason for the rename. I liked `locked_mark` because it was the "locked" version
of the original `mark`. I do like the use of the `const`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16603#discussion_r1396166107