<div dir="ltr">Thanks for your response, Vladimir.<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

VM stops compiling when it CodeCache is full, it is normal (no space left for compiled code). PermGen clean up means some classes were unloaded. During class unloading its methods are removed from CodeCache leaving some space for new compilations. </blockquote>

<div><br></div><div>So, if I'm reading this correctly, methods aren't removed from the code cache unless their class is gone, even if they haven't been called for a long time (and never will).</div><div><br></div>

<div><div>Based on your insights, I ran a few more experiments:</div><div><br></div><div>1. I tried sizing the perm gen so that it GCs before the code cache fills up. That seems to work around the problem, but it's very tricky to manage and tune in a real system.</div>
<div>2. I modified the program to call System.gc() every second and ran it with -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -XX:+CMSClassUnloadingEnabled. This also works around the problem.</div><div>3. I disabled the call to System.gc() and ran it with -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -XX:+CMSClassUnloadingEnabled. And this is where it gets interesting:</div>
<div>   a. As long as I keep triggering GC (manually, from VisualVM) before the code cache fills up, everything works well.</div><div>   b. If I let the code cache fill up, the VM gets into the bad condition and does not recover no matter how many times I trigger GC afterwards to unload classes from the perm gen.</div>
</div><div><br></div><div>Regards,</div><div>Martin</div></div>
</div></div>