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

[Thomas Stüfe]

Hi Christoph,

Not a full review, just some small remarks.

Instead of using msync, how about using os::is_readable_pointer()? You
should be far enough in initialization to have initialized safefetch stubs.
That would tell you if the address is mapped. If that returns false, I'd
use mmap with MAP_FIXED_NOREPLACE.

Cheers, Thomas


On Thu, Sep 3, 2020 at 4:19 PM Christoph Göttschkes <
christoph.goettschkes at microdoc.com> wrote:

> Hi,
>
> please review and test the following patch:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8252500
> Webrev: https://cr.openjdk.java.net/~cgo/8252500/webrev.00
>
> 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 am about to execute the HotSpot tier1 JTreg tests on two different
> aarch64 machines, one with 4KB pages and 3 levels, the other with 4KB
> pages and 4 levels (see [1]).
>
> Please test the patch, review the implementation and give feedback.
>
> Thanks,
> Christoph
>
> [1] https://www.kernel.org/doc/Documentation/arm64/memory.txt
>
>