Why is HeapBaseMinAddress by default so large?
Thomas Stüfe
thomas.stuefe at gmail.com
Fri Aug 11 06:13:10 UTC 2023
Answering my question to the best of my ability:
There are two aspects to it; the aforementioned sbrk blockage on platforms
whose libc's implement malloc solely based on brk(); and safety against
accidental NULL dereferences.
The OSes have limits too. Linux has vm.mmap_min_addr, typically set to 64
KB. MacOS forbids mappings below 4 GB completely since M1. In all cases,
safety against NULL dereferencing has been cited as the reason for these
limits.
Unless I miss a third reason, I believe it would be fine to lower
HeapBaseMinAddress to low-MB values. Larger than the largest possible fixed
structure in the JVM (e.g. Klass can be > 4 MB in rare cases) to make us
crash reliably on NULL dereferences. But low enough to still afford us a
much larger part of the valuable low-address range below 4 GB.
Cheers, Thomas
On Fri, Jul 21, 2023 at 8:29 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:
> Hi,
>
> I am trying to understand why the default value for HeapBaseMinAddress is
> so large (2G on all of our platforms). When attempting to allocate heap or
> class space for unscaled encoding, this denies us half of the valuable
> space below 4G. I think it is unnecessary. Using lower address ranges is
> absolutely possible (e.g. Shenandoah reserves collection sets as low as
> 0x10000, and that works fine).
>
> One answer had been "because we don't want to obstruct sbrk() and cause
> malloc OOMs". But to my knowledge, the only platforms that had that
> particular problem were Solaris and AIX.
>
> Solaris is no more. AIX solves it differently and much smarter by
> declaring a configurable "no-reserve-zone" atop the sbrk() and preventing
> os::reserve_memory from mmap'ing there. That works wherever sbrk happens to
> be, and for every mapping the JVM reserves, not just for the heap.
>
> Looking through the history, I see that HeapBaseMinAddress was introduced
> by Vladimir in 2009 with 6791178: "Specialize for zero as the compressed
> oop vm heap base". From the start, the default values were mostly 2G. I
> could find no RFR thread for that change that discussed the
> patch. @Vladimir : do you maybe still know how you came up with the
> default?
>
> Thanks, Thomas
>
> [1] https://github.com/openjdk/jdk/commit/69f9ddee905f
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230811/aa36caaf/attachment.htm>
More information about the hotspot-dev
mailing list