RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 [v2]

[Aleksey Shipilev]

On Thu, 19 May 2022 16:46:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`.
>> 
>> I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion.
>> 
>> This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion.
>> 
>> Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range.
>> 
>> So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better

Marked as reviewed by shade (Reviewer).

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

> 4856: address MacroAssembler::zero_words(Register base, uint64_t cnt)
> 4857: {
> 4858:   guarantee(wordSize <= BlockZeroingLowLimit,

Surely, this `guarantee` would now never fire? Maybe we should demote it to `assert` to protect from accidental range error. There is no need to pay the price in release bits, I think.

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

PR: https://git.openjdk.java.net/jdk/pull/8756