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

Roman Kennke rkennke at openjdk.org
Wed Apr 26 11:26:56 UTC 2023


On Wed, 26 Apr 2023 09:03:07 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81:
>> 
>>> 79:   // C2CodeStubList::emit() will throw an assertion and report the actual size that
>>> 80:   // is needed.
>>> 81:   return 33;
>> 
>> This should be 36 with `ASSERT` and 21 without. If you are sure that `JavaThread::lock_stack_top_offset()` or `OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)` fits within an `int8_t` then it reduces 3 bytes for each usage.
>
> This stub has 2 instructions, and it seems not really uncommon, is it worth it to have a stub here?

Ok I will change the value.
Yes, this path is relatively uncommon (monitors are inflated only once, and not necessarily via ANONYMOUS handshake, but used often), and this path is performance relevant. The original impl had the two instructions inlined, but the common forward branch impacted performance.

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 781:
>> 
>>> 779: #ifdef _LP64
>>> 780:       C2HandleAnonOMOwnerStub* stub = new (Compile::current()->comp_arena()) C2HandleAnonOMOwnerStub(tmpReg, boxReg);
>>> 781:       Compile::current()->output()->add_stub(stub);
>> 
>> This should be added only if we are really emitting the code (i.e. not emitting into a scratch buffer to measure the node size)
>
> Also, I think this `if (LockingMode == LM_LIGHTWEIGHT)` block should be moved out of the enclosing if block, we are checking for inflation here, it seems logical to separate the inflation path out.

How would I check if we are emitting code?

I am not sure I understand. The check for ANONYMOUS is only relevant when we observe an already-inflated monitor. I think this is the right place to put it.

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

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


More information about the serviceability-dev mailing list