RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v7]

[Andrew Haley]

On Fri, 17 Oct 2025 04:19:42 GMT, Patrick Zhang <qpzhang at openjdk.org> wrote:

>> Issue: 
>> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check.
>> 
>> This PR:
>> 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled.
>> 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization.
>> 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. 
>> 
>> Tests:
>> 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected.
>> 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks.
>
> Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine the count types to pass mac and win builds
>   
>   Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6207:

> 6205:   assert(ptr == r10 && cnt == r11, "mismatch in register usage");
> 6206:   RuntimeAddress zero_blocks = RuntimeAddress(StubRoutines::aarch64::zero_blocks());
> 6207:   assert(zero_blocks.target() != nullptr, "zero_blocks stub has not been generated");

What is the point of this change?

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6236:

> 6234:   // The zero_blocks routine has already performed the necessary
> 6235:   // adjustments to r10 and r11, ensuring they are correctly set
> 6236:   // for subsequent processing.

Suggestion:

  // A few words remain. zero_blocks() has adjusted r10 so that it
  // points to the remaining words and adjusted the count in r11.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6268:

> 6266:   // and necessary unrolled str/stp expanding when the condition is not met.
> 6267:   // This approach also helps prevent sudden increases in code cache size
> 6268:   // when zeroing large memory areas in many places.

Suggestion:

  // There is no need to check UseBlockZeroing here because that is
  // delegated to the zero_blocks stub. The code here is inlined, so
  // it is important to keep it small.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6273:

> 6271:     result = zero_words(r10, r11);
> 6272:   } else {
> 6273: #ifndef PRODUCT

What is this change for?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2550284013
PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2550286280
PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2550291161
PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2550292504