JIT stops compiling after a while (java 7)

[Vladimir Kozlov]

On 8/14/13 11:24 PM, Martin Traverso wrote:
>     We have several bugs opened and we are working on them.
>
> Is there a bug report you could point me to?

Next one describes problem may be similar to yours but unfortunately it is confidential because it talks about internal 
Oracle's apps:

8020151: Large performance regressions when code cache is filled

"When the code cache fills up, performance becomes severely hampered. We've observed two scenarios: one where the 
performance drops by about 4x and remains steady, and one where the performance drops nearly 100% for a few minutes, 
gets to an 80% regression for a few minutes, eventually recovers all performance for a few minutes, and then repeats 
that cycle."

Vladimir

>
>     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,  CodeCacheFlushingMinimumFreeSp__ace, 1500*K,
>             "When less than X space left, start code cache cleaning")
>
> Tweaking these didn't seem to help.
>
>     If you can build fastdebug VM you can run it with -XX:+PrintMethodFlushing to see what happened.
>
> Here's a sample trace with PrintCompilation, PrintGCDetails and PrintMethodFlushing:
>
> https://github.com/martint/jittest/blob/master/stats-7u40-fastdebug.txt
>
> I can see GC events, and a bunch of messages from the sweeper, but not a single "flushing nmethod".
>
> Here's another run with the variant that calls System.gc() every second. This one does show "flushing nmethod" messages:
>
> https://github.com/martint/jittest/blob/master/stats-7u40-fastdebug-force-gc.txt
>
>
>     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.
>
>
> Yes, there are normal GC events throughout the entire execution.
>
>
> Thanks,
> Martin