<div dir="ltr"><div>Hi,</div><div><br></div><div>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).</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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?<br></div><div><br></div><div>Thanks, Thomas</div><div><br></div><div>[1] <a href="https://github.com/openjdk/jdk/commit/69f9ddee905f">https://github.com/openjdk/jdk/commit/69f9ddee905f</a>       <br></div><div><br></div></div>