JIT stops compiling after a while (java 7)

[Vladimir Kozlov]

Martin,

There are definitely problems with UseCodeCacheFlushing in your case. It 
was designed exactly to handle such cases - free codecache from methods 
which are not used for long time even if classes are still loaded. We 
have several bugs opened and we are working on them.

You can try to play with next 2 flags to see if it helps:

product(intx,  MinCodeCacheFlushingInterval, 30,
         "Min number of seconds between code cache cleaning sessions")

product(uintx,  CodeCacheFlushingMinimumFreeSpace, 1500*K,
        "When less than X space left, start code cache cleaning")

-XX:MinCodeCacheFlushingInterval=30 
-XX:CodeCacheFlushingMinimumFreeSpace=1500k

Can you build Hotspot VM yourself from our open source of Hotspot in 
7u40: http://hg.openjdk.java.net/hsx/hsx24/hotspot/ ?

If you can build fastdebug VM you can run it with 
-XX:+PrintMethodFlushing to see what happened.

Do you have normal GC events (young gen collections) 
-XX:+PrintGCDetails? Methods usage marking and CodeCache sweeping 
initiation happen only during safepoints (usually when GC is needed) 
when all java threads are stopped.

Regards,
Vladimir

On 8/14/13 12:29 PM, Martin Traverso wrote:
> Thanks for your response, Vladimir.
>
>     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.
>
>
> 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).
>
> Based on your insights, I ran a few more experiments:
>
> 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.
> 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.
> 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:
>     a. As long as I keep triggering GC (manually, from VisualVM) before
> the code cache fills up, everything works well.
>     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.
>
> Regards,
> Martin