RFR: 8319799: Recursive lightweight locking: x86 implementation [v10]

[Axel Boldt-Christmas]

On Tue, 23 Jan 2024 14:39:05 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Ok now I see.  We've popped off the only entry of the lock stack (not recursive), but if some other thread has inflated the monitor due to contention, we'll fail this CAS.
>> 
>> 
>>     // Try to unlock. Transition lock bits 0b00 => 0b01
>>     movptr(reg_rax, mark);
>>     andptr(reg_rax, ~(int32_t)markWord::lock_mask);
>>     orptr(mark, markWord::unlocked_value);
>>     lock(); cmpxchgptr(mark, Address(obj, oopDesc::mark_offset_in_bytes()));
>>     jcc(Assembler::notEqual, push_and_slow_path);
>>     jmp(unlocked);
>> 
>> 
>> The alternative you're suggesting is to instead of pushing back on the lock-stack, go to check_successor (which will be non-null due to the contention) and the handoff will be faster that way.  Then we have to restore the owner thread. Is the lock definitely never inflated due to hash code in this case now?
>> 
>> Let's explain this in another RFE and we can see if benchmark results support this optimization.  Pushing back on the lock stack and going slow path is simpler (less assembly code) and matches the interpreter/c1 case. But let's see after this is checked in. Your assert with some adjustment to the comment looks good.  I was trying to remove the concept of anonymous owner from the assembly code because of another change I was working on.  Thanks.
>
>> Is the lock definitely never inflated due to hash code in this case now?
> 
> It never inflates a locked object. The hash code race that may re-inflate a monitor is with deflation. Where it tries to install a hash code on an inflated monitor, but the monitor gets deflated between the two reads of the markWord, the thread that tries to install the hash code will create a new ObjectMonitor. [JDK-8323724](https://bugs.openjdk.org/browse/JDK-8323724) RFE is created for that issue.

Hmm now that I think about it can still happen that it inflates a fast locked lock. If a third thread enters at the same time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16607#discussion_r1463385676