RFR: 8320280: RISC-V: Avoid passing t0 as temp register to MacroAssembler::lightweight_lock/unlock [v2]

Robbin Ehn rehn at openjdk.org
Mon Nov 20 09:53:33 UTC 2023


On Mon, 20 Nov 2023 09:41:00 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> This is inspired by https://bugs.openjdk.org/browse/JDK-8316880.
>> MacroAssembler::lightweight_lock/unlock is non-trivial on linux-riscv64 platform. Passing t0(aka x5) as temporary register to these two assember functions can also be error prone. As a reserved scratch register, t0 is implicitly clobberred by various assembler functions. This fixes the issue by finding and passing a different register, which is similar with https://bugs.openjdk.org/browse/JDK-8316880.
>> 
>> ### Testing:
>> - [x]  Run tier1-3 tests with qemu 8.1.50 (default locking mode) (release)
>> - [x]  Run non-trivial benchmark workloads (specjbb2005, dacapo, renaissance) with -XX:LockingMode=2 (fastdebug & release)
>> - [x] hotspot:tier4 on hifive unmatched (release)
>
> Gui Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update some assertions for calls to MacroAssembler::lightweight_lock/unlock

Hi, thanks!

Sorry with calle I meant all methods that have cmpxchg in them, such
macroAssembler_riscv.cpp: MacroAssembler::lightweight_(un)lock
Where this assert is also assert_different_registers(obj, hdr, tmp1, tmp2);
So there are a couple of more, sorry.

There also a special cmpxchg_obj_header which still uses t0.
You want to fix that in this same PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16703#issuecomment-1818706761


More information about the hotspot-compiler-dev mailing list