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

[Axel Boldt-Christmas]

On Thu, 16 Nov 2023 19:05:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I see what you mean. Because we need to put the hash code in the ObjectMonitor if it already is inflated and it may be the case that the ObjectMonitor has an anonymous owner we can still call `is_lock_owned` when retrieving the monitor for FastHashCode. 
>> 
>> Technically we could condition the inflate call on if the mark word lock bits and pick out the ObjectMonitor from the mark word. It would always be installed when reaching that point in the LM_LIGHTWEIGHT mode.
>
> Do we inflate when the VMThread is doing JVM/TI tagging?

LM_LEGACY and LM_MONITOR will. LM_LIGHTWEIGHT technically may. If deflation finishes between reading the mark word in FastHashCode and reading the mark word in `inflate`. It seems like a rare enough case that it does not need to be handled separately. The following change would avoid inflation all together.

    // An async deflation can race after the inflate() call and before we
    // can update the ObjectMonitor's header with the hash value below.
+   if (LockingMode == LM_LIGHTWEIGHT) {
+     assert(mark.has_monitor(), "must be");
+     monitor =  mark.monitor();
+   } else {
-   monitor = inflate(current, obj, inflate_cause_hash_code);
+     monitor = inflate(current, obj, inflate_cause_hash_code);
+   }
    // Load ObjectMonitor's header/dmw field and see if it has a hash.


Maybe I should change it to this. Given that there has been confusion here.
My ideal solution would be to separate the implementations for the different locking modes all together, all of these functions are littered with if (LockingMode == X).

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

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