<div dir="ltr">Thank you, Vladimir.<div><br></div><div>Issue: <a href="https://bugs.openjdk.org/browse/JDK-8331185">https://bugs.openjdk.org/browse/JDK-8331185</a> and proposed </div><div>PR: <a href="https://github.com/openjdk/jdk/pull/18969">https://github.com/openjdk/jdk/pull/18969</a> </div><div><br></div><div>I am curious if testing shakes any pre-existing bugs loose.</div><div><br></div><div>Cheers, Thomas</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 22, 2024 at 7:35 PM Vladimir Kozlov <<a href="mailto:vladimir.kozlov@oracle.com">vladimir.kozlov@oracle.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">Hi Thomas,<br>
<br>
I like option 1).<br>
<br>
I think 1Gb is reasonable starting value - I know that C2 may ease eat <br>
512Kb of memory.<br>
But before we set exact value we need to test it in all our tiers.<br>
I don't want to create a lot of failures which we will not have time to <br>
fix fast. It should be rare case as you stated.<br>
<br>
We also need to decide how we fix/avoid such failure:<br>
<br>
1. Recompile with some optimizations off (I assume we can tell which <br>
optimization triggers big memory consumption and safely bailout from <br>
compilation)<br>
2. Recompile with some inlining off<br>
3. Mark method not compilable by corresponding compiler<br>
...<br>
<br>
Please file RFE and PR. We will help with testing.<br>
<br>
Thanks,<br>
Vladimir K<br>
<br>
On 4/12/24 12:30 AM, Thomas Stüfe wrote:<br>
> Hi,<br>
> <br>
> Issues like <a href="https://bugs.openjdk.org/browse/JDK-8330103" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8330103</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8330103" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8330103</a>> show that compiler memory <br>
> consumption can be an issue.<br>
> <br>
> Since <a href="https://bugs.openjdk.org/browse/JDK-8318016" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8318016</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8318016" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8318016</a>>, we have an optional <br>
> per-compilation memory limit. If we reach that limit, one of two things <br>
> (configurable) happens: we either assert or abort the compilation.<br>
> <br>
> These memory limits build on the compiler memory statistic added with <br>
> <a href="https://bugs.openjdk.org/browse/JDK-8317683" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8317683</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8317683" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8317683</a>>. Enabling <br>
> memory limits also enables memory statistics.<br>
> <br>
> Some ideas:<br>
> <br>
> 1) We could enable a reasonable memory limit per default for debug <br>
> builds. Preferably combined with the assert option. That way, we run all <br>
> tests on a debug VM with memory limits enabled. If there are <br>
> pathological compilations during testing, we will notice them.<br>
> <br>
> (I don't know if we would notice them today; even if testers let JVMs <br>
> run with outside ulimits, these limits are typically very high to allow <br>
> for the total expected memory consumption of the test JVM).<br>
> <br>
> Such a memory limit could be set at whatever we feel is pathological, <br>
> e.g., several hundred MB. Even set at 1GB, we would hopefully see cases <br>
> like 8318016 in our tests.<br>
> <br>
> 2) If we don't want (1), we could at least enable memory statistics by <br>
> default for debug builds and print it out to hs-err files.<br>
> <br>
> 3) We could also enable memory limits in release builds and bail out of <br>
> the compilations. A small cost is involved, probably negligible: on <br>
> Arena enlargement, we increase several thread local counters. <br>
> Unfortunately, there is a small risk, too, in that bailout paths in C2 <br>
> may be broken, leading to follow-up errors. We fixed them all, I think, <br>
> but there is a remaining risk. OTOH, using up excessive amounts of <br>
> memory is also not optimal.<br>
> <br>
> What do you think? Would this make sense? If (1) makes sense to you, <br>
> what limit would be reasonable?<br>
> <br>
> Cheers, Thomas<br>
> <br>
> <br>
> <br>
> <br>
> <br>
</blockquote></div>