<div dir="ltr">> <span style="font-size:12.8px">For real world applications I hope that this is a much smaller issue but if you must load and execute loads and loads of short lived classes then it might be reasonable to disable concurrent class unloading (at the cost of getting serial Full gcs instead).</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Unfortunately, this is not a theoretical issue for us. We see this problem running Presto (<a href="http://prestodb.io">http://prestodb.io</a>), which generates bytecode for every query it processes. For now, we're working around it with a background thread that watches the size of the code cache and calls System.gc() when it gets close to the max (<a href="https://github.com/facebook/presto/commit/91e1b3bb6bbfffc62401025a24231cd388992d7c">https://github.com/facebook/presto/commit/91e1b3bb6bbfffc62401025a24231cd388992d7c</a>).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Martin</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 1, 2016 at 5:17 AM, Mikael Gerdin <span dir="ltr"><<a href="mailto:mikael.gerdin@oracle.com" target="_blank">mikael.gerdin@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<span class=""><br>
<br>
On 2016-03-01 13:35, Tobias Hartmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
is just had a another look and it turned out that even with 8u40+ class unloading is triggered. I missed that because it happens *much* later (compared to 8u33) when the code cache already filled up and compilation is disabled. At this point we don't recover because new classes are loaded and new OSR nmethods are compiled rapidly.<br>
<br>
Summary:<br>
The code cache fills up due to OSR nmethods that are not being flushed. With 8u33 and earlier, G1 did more aggressive class unloading (probably due to more allocations or different heuristics) and this allowed the sweeper to flush enough OSR nmethods to continue compilation. With 8u40 and later, class unloading happens long after the code cache is full.<br>
</blockquote>
<br></span>
Before 8u40 G1 could only unload classes at Full GCs.<br>
After 8u40 G1 can unload classes at the end of a concurrent GC cycle, avoiding Full GC.<br>
<br>
If you run the test with CMS with +CMSClassUnloadingEnabled you will probably see similar problematic results since the class unloading in G1 is very similar to the one in CMS.<br>
I haven't investigated in depth why the classes do not get unloaded in the G1 and CMS cases but there are several known quirks with how concurrent class unloading behaves which causes them to unload classes later than the serial Full GC.<br>
<br>
Running G1 with -XX:-ClassUnloadingWithConcurrentMark<br>
or CMS with -XX:-CMSClassUnloadingEnabled<br>
disables concurrent class unloading completely and works around the issue you are seeing.<br>
<br>
For real world applications I hope that this is a much smaller issue but if you must load and execute loads and loads of short lived classes then it might be reasonable to disable concurrent class unloading (at the cost of getting serial Full gcs instead).<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think we should fix this by flushing "cold" OSR nmethods as well (JDK-8023191). Thomas Schatzl mentioned that we could also trigger a concurrent mark if the code cache is full and hope that some classes are unloaded but I'm afraid this is too invasive (and does not help much in the general case).<br>
</blockquote>
<br></span>
If it is possible to flush OSR nmethods without doing a full class unloading cycle then I think that path is prefereable.<span class="HOEnZb"><font color="#888888"><br>
<br>
/Mikael</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Opinions?<br>
<br>
Best regards,<br>
Tobias<br>
<br>
On 01.03.2016 11:27, Tobias Hartmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Nileema,<br>
<br>
thanks for reporting this issue!<br>
<br>
CC'ing the GC team because this seems to be a GC issue (see evaluation below).<br>
<br>
On 29.02.2016 23:59, nileema wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We are seeing an issue with the CodeCache becoming full which causes the<br>
compiler to be disabled in jdk-8u45 to jdk-8u72.<br>
<br>
We had seen a similar issue in Java7 (old issue:<br>
<a href="http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-August/011333.html" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-August/011333.html</a>).<br>
This issue went away with earlier versions of Java 8.<br>
</blockquote>
<br>
Reading the old conversation, I'm wondering if this could again be a problem with OSR nmethods that are not flushed? The bug (JDK-8023191) is still open - now assigned to me.<br>
<br>
Doing a quick experiment, it looks like we mostly compile OSR methods:<br>
22129 2137 % 3 Runnable_412::run @ 4 (31 bytes)<br>
22130 2189 % 4 Runnable_371::run @ 4 (31 bytes)<br>
22134 2129 % 3 Runnable_376::run @ 4 (31 bytes)<br>
22136 2109 % 3 Runnable_410::run @ 4 (31 bytes)<br>
<br>
Currently, OSR nmethods are not flushed just because the code cache is full but only if the nmethod becomes invalid (class loading/unloading, uncommon trap, ..)<br>
<br>
With your test, class unloading should happen and therefore the OSR nmethods *should* be flushed.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We used the test <a href="http://github.com/martint/jittest" rel="noreferrer" target="_blank">http://github.com/martint/jittest</a> to compare the behavior<br>
of jdk-8u25 and jdk-8u45. For this test, we did not see any CodeCache full<br>
messages with jdk-8u25 but did see them with 8u45+ (8u60 and 8u74)<br>
Test results comparing 8u25, 8u45 and 8u74:<br>
<a href="https://gist.github.com/nileema/6fb667a215e95919242f" rel="noreferrer" target="_blank">https://gist.github.com/nileema/6fb667a215e95919242f</a><br>
<br>
In the results you can see that 8u25 starts collecting the code cache much<br>
sooner than 8u45. 8u45 very quickly hits the limit for code cache. If we<br>
force a full gc when it is about to hit the code cache limit, we see the<br>
code cache size go down.<br>
</blockquote>
<br>
You can use the following flags to get additional information:<br>
-XX:CICompilerCount=1 -XX:+PrintCompilation -XX:+PrintMethodFlushing -XX:+TraceClassUnloading<br>
<br>
I did some more experiments with 8u45:<br>
<br>
java -mx20g -ms20g -XX:ReservedCodeCacheSize=20m -XX:+TraceClassUnloading -XX:+UseG1GC -jar jittest-1.0-SNAPSHOT-standalone.jar | grep "Unloading"<br>
-> We do *not* unload any classes. The code cache fills up with OSR nmethods that are not flushed.<br>
<br>
Removing the -XX:+UseG1GC flag solves the issue:<br>
<br>
java -mx20g -ms20g -XX:ReservedCodeCacheSize=20m -XX:+TraceClassUnloading -jar jittest-1.0-SNAPSHOT-standalone.jar | grep Unloading<br>
-> Prints plenty of [Unloading class Runnable_40 0x00000007c0086028] messages and the code cache does not fill up.<br>
-> OSR nmethods are flushed because the classes are unloaded:<br>
21670 970 % 4 Runnable_87::run @ -2 (31 bytes) made zombie<br>
<br>
The log files look good:<br>
<br>
1456825330672 112939 10950016 10195496 111.28<br>
1456825331675 118563 11432256 10467176 112.41<br>
1456825332678 125935 11972928 10778432 115.72<br>
[Unloading class Runnable_2498 0x00000007c0566028]<br>
...<br>
[Unloading class Runnable_34 0x00000007c0082028]<br>
1456825333684 131493 10220608 5382976 117.46<br>
1456825334688 137408 10359296 5636120 116.81<br>
1456825335692 143593 7635136 5914624 114.21<br>
<br>
After the code cache fills up, we unload classes and therefore flush methods and start over again.<br>
<br>
I checked for several releases if classes are unloaded:<br>
- 8u27: success<br>
- 8u33: success<br>
- 8u40: fail<br>
- 8u45: fail<br>
- 8u76: fail<br>
<br>
The regression was introduced in 8u40.<br>
<br>
I also tried with the latest JDK 9 build and it fails as well (had to change the bean name from "Code Cache" to "CodeCache" and run with -XX:-SegmentedCodeCache). Again, -XX:-UseG1GC -XX:+UseParallelGC solves the problem.<br>
<br>
Can someone from the GC team have a look?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is this a known issue?<br>
</blockquote>
<br>
I'm not aware of any related issue.<br>
<br>
Best regards,<br>
Tobias<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks!<br>
<br>
Nileema<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://openjdk.5641.n7.nabble.com/JIT-stops-compiling-after-a-while-java-8u45-tp259603.html" rel="noreferrer" target="_blank">http://openjdk.5641.n7.nabble.com/JIT-stops-compiling-after-a-while-java-8u45-tp259603.html</a><br>
Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com.<br>
<br>
</blockquote></blockquote></blockquote>
</div></div></blockquote></div><br></div>