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

Thomas Stuefe stuefe at openjdk.org
Tue Apr 4 08:20:44 UTC 2023


On Tue, 4 Apr 2023 05:54:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> 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.

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

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


More information about the serviceability-dev mailing list