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

[Daniel D. Daugherty]

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

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

Now I think I see why you changed the `cas_set_mark()` call to return its value into
`mark` instead of `old_mark` and why the original parameter to the CAS was changed
from `mark` to `old_mark`. It's a bit different style then we typically use for CAS where
the return value goes into an `old_something` variable.

Since `mark` is now the loop control and `old_mark` is now `const` you had to juggle
things with the `cas_set_mark()` call. Okay, I think I get the reason for this bit of juggling.
(I still don't understand the rename from `locked_mark` to `new_mark` but that's okay.)

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

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