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

[David Holmes]

On Tue, 4 Apr 2023 08:17:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9739:
>> 
>>> 9737:   get_thread(thread);
>>> 9738: #endif
>>> 9739:   subl(Address(thread, JavaThread::lock_stack_top_offset()), oopSize);
>> 
>> Is this code used for monitorexit or only returning from synchronized methods? If used for monitorexit there is no requirement that the monitor being unlocked was the last monitor locked. Balanced locking only requires the locks and unlocks are matched, not that they are perfectly nested ie. this is valid in bytecode:
>> 
>> monitorenter A
>> monitorenter B
>> monitorexit A
>> monitorExit B
>
> That is done one layer up in InterpreterMacroAssembler::unlock_object.

Thanks @tstuefe . I see at that level if the object doesn't match the top of the lock-stack then we take the slow path. But then I'm lost - AFAICS the slow path is `InterpreterRuntime::monitorexit` and that doesn't have any fast-locking code in it at all ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157169176