RFR: 8291555: Implement alternative fast-locking scheme [v4]

[Roman Kennke]

On Wed, 25 Jan 2023 17:42:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert UseFastLocking to default to off
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1141:
> 
>> 1139:       assert(_recursions == 0, "invariant");
>> 1140:       set_owner_from_BasicLock(cur, current);  // Convert from BasicLock* to Thread*.
>> 1141:       _recursions = 0;
> 
> Hmmm... fast-locking also has two different ways that a thread can own an
> ObjectMonitor: 1) owner == thread* and 2) owner == anonymous and lock on
> the owning thread's lock stack.
> 
> If `UseFastLocking` is enabled and `ObjectMonitor::exit()` is called by a thread that
> owns the ObjectMonitor in the secondary way, then this code will fail the assert on
> L1158 in non-product bits. There needs to be check to see if the current thread owns
> the fast-lock and then update the owner in the ObjectMonitor after asserting about
> recursions and resetting recursions to 0.

With fast-locking, OM::exit() must not be called as long as the owner is ANONYMOUS. The protocol is the following:
- T1 fast-locks object O
- T2 attempts to lock object O, observes that it is already locked and inflates with ANONYMOUS owner, because it doesn't know who owns the monitor. It then gets in line to acquire the monitor.
- When T1 exits, it observes the monitor being owned by ANONYMOUS, and sets the owner to itself, and calls OM::exit(), thereby performing the regular hand-over to T2.
- That check for ANONYMOUS owner also needs to be done in the C2 fast-path, and when that happens, it calls into runtime to do the necessary hand-over.

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

PR: https://git.openjdk.org/jdk/pull/10907