<div dir="ltr">Hi,<br><div><br>Issues like <a href="https://bugs.openjdk.org/browse/JDK-8330103">https://bugs.openjdk.org/browse/JDK-8330103</a> show that compiler memory consumption can be an issue.<br></div><div><br></div><div>Since <a href="https://bugs.openjdk.org/browse/JDK-8318016">https://bugs.openjdk.org/browse/JDK-8318016</a>, we have an optional per-compilation memory limit. If we reach that limit, one of two things (configurable) happens: we either assert or abort the compilation.</div><div><br></div><div>These memory limits build on the compiler memory statistic added with <a href="https://bugs.openjdk.org/browse/JDK-8317683">https://bugs.openjdk.org/browse/JDK-8317683</a>. Enabling memory limits also enables memory statistics.</div><div><br></div><div>Some ideas:</div><div><br></div><div>1) We could enable a reasonable memory limit per default for debug builds. Preferably combined with the assert option. That way, we run all tests on a debug VM with memory limits enabled. If there are pathological compilations during testing, we will notice them. </div><div><br></div><div>(I don't know if we would notice them today; even if testers let JVMs run with outside ulimits, these limits are typically very high to allow for the total expected memory consumption of the test JVM).</div><div><br></div><div>Such a memory limit could be set at whatever we feel is pathological, e.g., several hundred MB. Even set at 1GB, we would hopefully see cases like 8318016 in our tests.</div><div><br></div><div>2) If we don't want (1), we could at least enable memory statistics by default for debug builds and print it out to hs-err files.</div><div><br></div><div>3) We could also enable memory limits in release builds and bail out of the compilations. A small cost is involved, probably negligible: on Arena enlargement, we increase several thread local counters. Unfortunately, there is a small risk, too, in that bailout paths in C2 may be broken, leading to follow-up errors. We fixed them all, I think, but there is a remaining risk. OTOH, using up excessive amounts of memory is also not optimal.</div><div><br></div><div>What do you think? Would this make sense? If (1) makes sense to you, what limit would be reasonable?</div><div><br></div><div>Cheers, Thomas</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>