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

[Andrew Haley]

On Mon, 15 Dec 2025 10:26:54 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:
> 
>   Renamed the vars to unroll_words
>   
>   Signed-off-by: Patrick Zhang <patrick at os.amperecomputing.com>

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

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

Suggestion:

  // The code here is inlined, so it is important to keep it small.

I find this "There is no need..." comment more confusing than helpful.

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

> 6275: #endif
> 6276:     // Use 16 words (128 bytes) as the block size to unroll.
> 6277:     const int unroll_words = 2 * MacroAssembler::zero_words_block_size;

const int unroll_words = 2 * MacroAssembler::zero_words_block_size;


I do not believe this makes the code easier to understand. It's explicitly two DC ZVA blocks. Maybe `two_blocks` or somesuch would be clearer to the reader.

The "replace literal constants with named constants" advice helps when the named constant is informative, which `unroll_words` is not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2685676711
PR Review Comment: https://git.openjdk.org/jdk/pull/26917#discussion_r2685668103