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