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

[Roman Kennke]

On Thu, 30 Mar 2023 11:45:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I have another question about the asymmetric unlocking code in `InterpreterMacroAssembler::unlock_object`.
>> 
>> We go through here for both fast-locked and fat OM locks, right? If so, shouldn't we do the asymmetric lock check only for the fast locked case? Otherwise Lockstack may be empty, so we compare the word preceding the first slot, which would cause us to always break into the slow case?
>> 
>> Sorry if I miss something here.
>
>> I have another question about the asymmetric unlocking code in `InterpreterMacroAssembler::unlock_object`.
>> 
>> We go through here for both fast-locked and fat OM locks, right? If so, shouldn't we do the asymmetric lock check only for the fast locked case? Otherwise Lockstack may be empty, so we compare the word preceding the first slot, which would cause us to always break into the slow case?
>> 
>> Sorry if I miss something here.
> 
> Uh, yes, indeed. It works by accident, I suppose, because we don't segfault on the word preceding the lock-stack, and monitor-locking takes the slow-case in interpreter, anyway. But yeah, it's better to check for it.

> @rkennke Question about ZGC and LockStack::contains(): how does this work with colored pointers? Don't we have to mask the color bits out somehow when comparing? E.g. using `ZAddress::offset()` ?

We must ensure that the oops are in a valid state. I recently added code to ::contains() to call start_processing() when called from a foreign thread. When inspecting its own thread, we are always good, because stack-watermark is processed right after leaving a safepoint, before resuming normal operations.

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

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1490302961