RFR: 8252500: ZGC on aarch64: Unable to allocate heap for certain Linux kernel configurations [v2]

[Christoph Göttschkes]

On Mon, 7 Sep 2020 12:16:09 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp line 150:
>> 
>>> 148:   size_t max_address_bit = 0;
>>> 149:   const size_t page_size = os::vm_page_size();
>>> 150:   for (size_t i = DEFAULT_MAX_ADDRESS_BIT; i > MINIMUM_MAX_ADDRESS_BIT; --i) {
>> 
>> Should the loop condition be MINIMUM_MAX_ADDRESS_BIT *inclusive* instead of exclusive? Seems weird that it is
>> exclusive, when we later check if max_address_bit < MINIMUM_MAX_ADDRESS_BIT return MINIMUM_MAX_ADDRESS_BIT, which seems
>> like exactly what will happen if the loop would have advanced to MINIMUM_MAX_ADDRESS_BIT (and then finish the loop).
>
> Not sure how to comment a few lines below where you conditionally return MINIMUM_MAX_ADDRESS_BIT in this new cool GUI.
> Anyway, you could use MIN2 to return MIN2(MINIMUM_MAX_ADDRESS_BIT, max_address_bit) to make the intention more clear.

We are not processing MINIMUM_MAX_ADDRESS_BIT in the loop, because this is the absolute minimum that should be
returned. So, regardless of the probing result, we are going to return that value. Therefor, it is a waste of time to
actually perform the probe.

The check `max_address_bit < MINIMUM_MAX_ADDRESS_BIT` is done, because after the probing (if it failed and we didn't
find any valid page), right after the for loop, we do a single mmap and use the returned address to calculate the
`max_address_bit`. So `max_address_bit` could then be lower than `MINIMUM_MAX_ADDRESS_BIT`.

For the return part, you are right, we could simplify it by using `MAX2`, since we are interested in the highest bit,
and `MINIMUM_MAX_ADDRESS_BIT` is the absolute minimum we want to return.

I will push an update for the return part.

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

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