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 6281:

> 6279: #endif
> 6280:     // Use 16 words as the block size which is 128 bytes on 64-bit systems.
> 6281:     // A complete loop body will be 8 STPs unrolled there.

Suggestion:

    // Use 16 words (128 bytes) as the block size.

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

> 6280:     // Use 16 words as the block size which is 128 bytes on 64-bit systems.
> 6281:     // A complete loop body will be 8 STPs unrolled there.
> 6282:     const int block_size = 16;

Naming this constant `block_size` only adds to any confusion, IMO.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 694:

> 692:       // Process words with length exceeding the predefined
> 693:       // block size threshold. The loop body will be unrolled based on
> 694:       // the number of STPs calculated below.

Suggestion:

      // Process any remaining blocks not handled by the stub.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2550303883
PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2550306382
PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2550310021