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

Roman Kennke rkennke at openjdk.org
Thu Mar 30 13:35:14 UTC 2023


On Tue, 28 Mar 2023 00:17:21 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure safepoint when processing lock-stack
>
> src/hotspot/cpu/aarch64/aarch64.ad line 3844:
> 
>> 3842: 
>> 3843:         // Indicate success on completion.
>> 3844:         __ cmp(oop, oop); // Force ZF=1 to indicate success.
> 
> It looks like `fast_lock` already sets ZF=1 on success/fall-through.  Why not document this as part of the interface, then this `cmp` will be redundant?

Indeed. I was assuming that the instructions that follow the CAS might be affecting the NZCV flags (like they do on x86), but apparently they don't. Very nice. I am removing the instruction here and following fast_unlock().

> src/hotspot/share/interpreter/interpreterRuntime.cpp line 740:
> 
>> 738:   if (!UseHeavyMonitors && UseFastLocking) {
>> 739:     // This is a hack to get around the limitation of registers in x86_32. We really
>> 740:     // send an oopDesc* instead of a BasicObjectLock*.
> 
> I don't understand what this is referring to.  Trying to avoid passing an extra argument?

I updated the comment in an earlier commit to say:
   // TODO: We accept elem as void* to workaround a limitation of registers in x86_32. Interpreter
    // code is really sending an oopDesc* here.
    // The problem is that we would need to preserve the register that holds the BasicObjectLock,
    // but we are using that register to hold the thread. We don't have enough registers to
    // also keep the BasicObjectLock, but we don't really need it anyway, we only need
    // the object. See also InterpreterMacroAssembler::lock_object().
    // As soon as traditional stack-locking goes away we can change elem to be oopDesc*
    // (also in monitorexit below).
I hope that is clearer.

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

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


More information about the serviceability-dev mailing list