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