[ZGC] [aarch64] Unable to allocate heap for certain Linux kernel configurations
stefan.karlsson at oracle.com
Mon Aug 31 10:47:57 UTC 2020
On 2020-08-31 10:29, Christoph Göttschkes wrote:
> Hi Stuart.
> On 2020-08-28 16:56, Stuart Monteith wrote:
>> That's right - I have been exploring options on this, and I had a
>> similar solution at one point to finding the address space size. From
>> speaking with people familiar with the arm64 linux kernel, there is no
>> good way to query the available address space except for probining it
>> and testing what is there. Thinking we could do with a general-purpose
>> routine, I experimented with a routine that forks the process and
>> probes the address space non-destructively. MAP_FIXED implicitly
>> destroys any existing mappings. Of course, ZGC mmaps memory at fixed
>> addresses anyhow, so the concern about embedded the JVM in your
>> program and destroying existing mappings turned out to be moot, as
>> we'd be doing that anyway.
> After reading your comment, the only other viable solution I came up
> with is using a combination of msync and mmap. I didn't fully look into
> this yet, but made a small prototype to show you the idea and to get
> early feedback. Maybe someone already looked into this and knows that
> some edge case doesn't work.
> General idea:
> First use msync to check if there is already a mapping for the page. If
> msync returns ENOMEM, this either means: there is no mapping yet, or the
> address is invalid. After getting ENOMEM, we can use mmap to try and map
> the page. If we get back the same address, we know the address is valid.
> If the address is different, we know it is invalid. I also don't want to
> use MAP_FIXED, but maybe MAP_FIXED_NOREPLACE (as mentioned by Florian)
> would be a solution, but it was only introduced in Linux 4.17, so I
> guess we would need a fallback solution.
> I tested this on different Linux aarch64 devices and it seems to work.
> You can find the prototype here:
General approach seems fine to me. Maybe someone more well-versed in
msync can chime in?
Some comments about the patch:
- Maybe check for EINVAL and/or add an assert to catch the odd error
codes in debug builds?
- If no max bits are found, the subsequent code will underflow. I think
returning some kind of lower-limit that works with the code in
ZPlatformAddressOffsetBits would be prudent.
A few things that will make the code look more like HotSpot code:
- We usually use os::vm_pages_size() instead of sysconf(_SC_PAGE_SIZE).
- 'sizeof(uintptr_t) * CHAR_BIT' maybe replace with BitsPerWord
- %zu use SIZE_FORMAT instead
> -- Christoph
More information about the hotspot-gc-dev