RFR: 8295282: Use Zicboz/cbo.zero to zero-out memory on RISC-V [v11]

[Ludovic Henry]

On Mon, 24 Oct 2022 07:43:17 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Still several more comments. What kind of tests has been carried out for this change?

I've run `hotspot:tier1` tests on a QEMU with support for `Zicbo{z,p,m}`

> src/hotspot/cpu/riscv/globals_riscv.hpp line 90:
> 
>> 88:           "Minimum size in bytes when block zeroing will be used")               \
>> 89:           range(1, max_jint)                                                     \
>> 90:   product(intx, CacheLineSize, DEFAULT_CACHE_LINE_SIZE,                          \
> 
> Given that 64 bytes is effectively an industry standard, I don't think we need to add "CacheLineSize" as an option at this stage. It will be safer if everything here only depend on "UseZic64b" option which only implies cache block size of 64 bytes. This would also simplify the changes in file: src/hotspot/cpu/riscv/vm_version_riscv.cpp.

Is there is no guarantee that a platform will provide both `Zicboz` _and_ `Zic64b` even if the cache lines are 64 bytes? As in, the cache lines are 64 bytes, but the CPU doesn't notify the kernel that it supports `Zic64b`?

In that case, we won't use `Zicboz` which can be significantly faster than other approaches to zero out memory (the CPU is free not to fetch a cache line before storing it, since the whole cache line is zeroed out). Given the overall cost of zeroing out memory in Java, it's necessary to ensure it's as fast as possible.

I overall agree with the 64 bytes is an industry standard. What I want to ensure is that we can eagerly enable `UseBlockZeroing` whenever we can.

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

PR: https://git.openjdk.org/jdk/pull/10718