Why is HeapBaseMinAddress by default so large?

[Thomas Stüfe]

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/20230721/6c1cfa49/attachment.htm>