RFR: 8351140: RISC-V: Intrinsify Unsafe::setMemory [v10]

[Feilong Jiang]

On Fri, 16 May 2025 08:11:16 GMT, Anjian-Wen <duke at openjdk.org> wrote:

>> From [JDK-8329331](https://bugs.openjdk.org/browse/JDK-8329331), add riscv unsafe::setMemory intrinsic’s generator generate_unsafe_setmemory. This intrinsic optimizes about quite a lot unsafe setmemory time
>> 
>> on my musebook, the JMH test micro:java.lang.foreign.MemorySegmentZeroUnsafe shows below
>> 
>> before the patch
>> 
>> Benchmark                       (aligned)  (size)  Mode  Cnt   Score   Error  Units
>> MemorySegmentZeroUnsafe.panama       true       1  avgt   30   24.198 ± 0.392  ns/op
>> MemorySegmentZeroUnsafe.panama       true       2  avgt   30   20.688 ± 0.013  ns/op
>> MemorySegmentZeroUnsafe.panama       true       3  avgt   30   20.703 ± 0.045  ns/op
>> MemorySegmentZeroUnsafe.panama       true       4  avgt   30   20.053 ± 0.016  ns/op
>> MemorySegmentZeroUnsafe.panama       true       5  avgt   30   20.682 ± 0.016  ns/op
>> MemorySegmentZeroUnsafe.panama       true       6  avgt   30   20.732 ± 0.061  ns/op
>> MemorySegmentZeroUnsafe.panama       true       7  avgt   30   21.403 ± 0.096  ns/op
>> MemorySegmentZeroUnsafe.panama       true       8  avgt   30   25.268 ± 0.197  ns/op
>> MemorySegmentZeroUnsafe.panama       true      15  avgt   30   27.481 ± 0.195  ns/op
>> MemorySegmentZeroUnsafe.panama       true      16  avgt   30   27.577 ± 0.019  ns/op
>> MemorySegmentZeroUnsafe.panama       true      63  avgt   30  208.893 ± 2.795  ns/op
>> MemorySegmentZeroUnsafe.panama       true      64  avgt   30  199.167 ± 0.936  ns/op
>> MemorySegmentZeroUnsafe.panama       true     255  avgt   30  220.672 ± 0.879  ns/op
>> MemorySegmentZeroUnsafe.panama       true     256  avgt   30  246.256 ± 0.756  ns/op
>> MemorySegmentZeroUnsafe.panama      false       1  avgt   30   23.849 ± 0.088  ns/op
>> MemorySegmentZeroUnsafe.panama      false       2  avgt   30   20.671 ± 0.006  ns/op
>> MemorySegmentZeroUnsafe.panama      false       3  avgt   30   20.694 ± 0.037  ns/op
>> MemorySegmentZeroUnsafe.panama      false       4  avgt   30   20.048 ± 0.010  ns/op
>> MemorySegmentZeroUnsafe.panama      false       5  avgt   30   20.684 ± 0.020  ns/op
>> MemorySegmentZeroUnsafe.panama      false       6  avgt   30   20.685 ± 0.016  ns/op
>> MemorySegmentZeroUnsafe.panama      false       7  avgt   30   21.383 ± 0.086  ns/op
>> MemorySegmentZeroUnsafe.panama      false       8  avgt   30   25.684 ± 0.006  ns/op
>> MemorySegmentZeroUnsafe.panama      false      15  avgt   30   27.593 ± 0.043  ns/op
>> MemorySegmentZeroUnsafe.panama      false      16  avgt   30   28.437 ± 0.228  ns/o...
>
> Anjian-Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   RISC-V: Intrinsify Unsafe::setMemory

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1665:

> 1663:     Label L_exit, L_fill_elements, L_loop;
> 1664: 
> 1665:     const Register to = c_rarg0;

As the comments said before, we can use `dest` instead of `to`.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1743:

> 1741:     // Handle copies less than 8 bytes
> 1742:     __ bind(L_fill_elements);
> 1743:     __ beqz(count, L_exit);

If `count` may be zero, we can put `beqz` at the beginning of the stub.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1749:

> 1747:     __ addi(to, to, 1);
> 1748:     __ subi(count, count, 1);
> 1749:     __ bnez(count, L_loop);

If we unroll the byte storage, will there be additional performance gains when the "count" is less than 8?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23890#discussion_r2094323633
PR Review Comment: https://git.openjdk.org/jdk/pull/23890#discussion_r2094342362
PR Review Comment: https://git.openjdk.org/jdk/pull/23890#discussion_r2094344728