<div dir="ltr">Answering my question to the best of my ability:<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers, Thomas</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 21, 2023 at 8:29 AM Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com">thomas.stuefe@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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" target="_blank">https://github.com/openjdk/jdk/commit/69f9ddee905f</a>       <br></div><div><br></div></div>
</blockquote></div>