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

[Christoph Göttschkes]

On Mon, 7 Sep 2020 09:59:55 GMT, Christoph Göttschkes <cgo at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp line 156:
>> 
>>> 154:       max_address_bit = i;
>>> 155:       break;
>>> 156:     }
>> 
>> Is there a one-off error here? Taking i == 47 as an example. This means that you test the base_address == '10000000
>> 00000000 00000000 00000000 00000000 00000000' (in bits). That is, you test that the address range with the 48th bit set
>> (128T-256T) is usable. However, when 47 then is returned to the caller, it interprets it as if the 64T-128T range is
>> usable.
>
> Good catch. I verified your assumption by doing the following:
> I returned the result of probe_valid_max_address_bit() + 1 from ZPlatformAddressOffsetBits(). I then executed a VM on a
> platform with only 3 pagetable levels, which has less than DEFAULT_MAX_ADDRESS_BIT bits available in the address space.
> The heap allocation succeeded, which means the current patch has a one off error.  However, I would fix this in
> ZPlatformAddressOffsetBits(). because I interpret the result of probe_valid_max_address_bit() as to be the highest bit
> index of an address which can be allocated. Which means that mmap the result of 1 << probe_valid_max_address_bit()
> should succeed (if the page is not already mapped). I think ZPlatformAddressOffsetBits() should add 1 to the result of
> probe_valid_max_address_bit().

Sorry, the explanation of my verification was wrong. I did the following:

size_t ZPlatformAddressOffsetBits() {
  const static size_t valid_max_address_bit = probe_valid_max_address_bit();
  const size_t max_address_offset_bits = valid_max_address_bit - 3;
  return max_address_offset_bits + 1;
}

and allocation of the Java heap succeeded.

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

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