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

[Christoph Göttschkes]

> The patch introduces a new function to probe for the highest valid bit in the virtual address space for userspace
> programs on Linux.
> I guarded the whole implementation to only probe on Linux, other platforms will remain unaffected. Possibly, it would
> be nicer to move the probing code into an OS+ARCH specific source file. But since this is only a single function, I
> thought it would be better to put it right next to the caller and guard it with an #ifdef LINUX.  The probing mechanism
> uses a combination of msync + mmap, to first check if the address is valid using msync (if msync succeeds, the address
> was valid). If msync fails, mmap is used to check if msync failed because the memory wasn't mapped, or if it failed
> because the address is invalid. Due to some undefined behavior (documented in the msync man page), I also use a single
> mmap at the end, if the msync approach failed before.  I tested msync with different combinations of mappings, and also
> with sbrk, and it always succeeded, or failed with ENOMEM. I never got back any other error code.  The specified
> minimum value has been chosen "randomly". The JVM terminates (unable to allocate heap), if this minimum value is
> smaller than the requested Java Heap size, so it might be better to make the minimum dependent on the MaxHeapSize and
> not a compile time constant? I didn't want to make the minimum too big, since for aarch64 on Linux, the documented
> minimum would be 38 (see [1]).   I avoided MAP_FIXED_NOREPLACE, because according to the man page, it has been added in
> Linux 4.17. There are still plenty of stable kernel versions around which will not have that feature, which means we
> need to implement a workaround for it. Some of my test devices also have a kernel version lower than that.  I executed
> the HotSpot tier1 JTreg tests on two different aarch64 devices. One with 4KB pages and 3 page levels and the other with
> 4KB pages and 4 page levels. Tests passed on both devices.  [1]
> https://www.kernel.org/doc/Documentation/arm64/memory.txt

Christoph Göttschkes has updated the pull request incrementally with one additional commit since the last revision:

  Changed constants from #define to typed static const variables.
  Changed the log_warning to a log_warning_p, so it is reported in hs_err
  file.
  mummap the result of mmap directly after the mmap call to be able to
  break out of the loop, instead of check the max_address_bit ==
  0 precondition.
  Fixed an 'off by one' mistake.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/40/files
  - new: https://git.openjdk.java.net/jdk/pull/40/files/5bc71d40..5b1030bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=40&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=40&range=00-01

  Stats: 12 lines in 1 file changed: 3 ins; 2 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/40.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/40/head:pull/40

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