<div dir="ltr"><div>Hi,<br></div><div><br></div><div>I recently looked more closely at MaxRAM, and there are some things I cannot quite figure out. </div><div><br></div><div>MaxRAM has default values hard-coded into the JVM. Those values are quite low by today's standards, e.g. on x64, we run with a default value of 128 GB.</div><div><br></div><div>First off, these defaults had always been dependent on compiler (C1, C2) and architecture, for the whole observable repo history. Why, though? What do these defaults have to do with JIT and architecture?</div><div><br></div><div>In older JVMs (up to and including JDK11, changed with <a href="https://bugs.openjdk.org/browse/JDK-8222252">https://bugs.openjdk.org/browse/JDK-8222252</a>), we cap the amount of physical memory with MaxRAM: If you have a box of, say, 4 TB main memory, -XX:MaxRAMPercentage=25 will give you only 32 GB, not 1 TB.</div><div><br></div><div>After <a href="https://bugs.openjdk.org/browse/JDK-8222252">https://bugs.openjdk.org/browse/JDK-8222252</a>, it got more complex. Now, if you *manually* specify MaxRAMPercentage, you get the full physical memory. So, running with -XX:MaxRAMPercentage=25 will give you 1 TB. But if you instead relied on the default value of MaxRAMPercentage, which is 25, the 128 GB maximum still applies, and we still run with 32 GB.</div><div><br></div><div>The comment history under <a href="https://bugs.openjdk.org/browse/JDK-8222252">https://bugs.openjdk.org/browse/JDK-8222252</a> suggests that MaxRAM defaults are something of a safety belt not to use excessive memory. But then, 128GB is just an arbitrary number. I can see the point of a safety belt as %-of-physical memory (and the 25% is ingrained into all developers by now), but I don't get the additional cap at 32 GB. Well, it is conveniently still in range for CompressedOops. Was that the reason for the 128 GB?<br></div><div><br></div><div>Does anyone know more details?<br></div><div><br></div><div>Thomas<br></div><div><br></div></div>