<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
&gt; I want to point that -XX:+UseCodeCacheFlushing flag in jdk 6 may also cause crashes, as other customers found. So your&nbsp;<br>&gt; only choice is increase CodeCache. There are several things happening which may cause your problem. C2 use "uncommon&nbsp;<br>&gt; traps" when compiles methods with a profile which shows that some paths in code were not executed before the compilation&nbsp;<br>&gt; time. A compiled code has also dependencies on loaded classes. All this leads to deoptimization and throwing out&nbsp;<br>&gt; previously compiled code if original compiling conditions are invalidated. After that a method re-executed in&nbsp;<br>&gt; Interpreter and recompiled again if it is still hot. There are cases when a method is recompiled a lot of times and&nbsp;<br>&gt; eventually C2 marks it as not compilable. Method could be marked as not compilable for other reasons also. Also at the&nbsp;<br>&gt; same time methods which executed less frequent get enough invocations to be compiled. Also we don't do CodeCache&nbsp;<br>&gt; compression which leads to fragmentation of free space. So I can imaging a situation when a very hot methods were&nbsp;<br>&gt; deoptimized but there were no space left for recompiled code.<br>Hmmm.. That's a bit unfortunate. I have already started a run with both the flags (increase in code cache size as well as specifying flushing on). I tried to look crash bugs for this and so far only found ones that have been already fixed. Is the crash issue still open? As you know we are using JDK6 update 31.&nbsp;<span style="font-size: 10pt; ">But thank you for your detailed explanation. What I am interpreting from that is that even though we do not have dynamically loaded classes it is possible for the code cache to get full is what you are eluding to.</span><div><br></div><div>&gt; Increase CodeCache size and do some test runs with -XX:+PrintCompilation. Look for methods which compiled a lot times or&nbsp;<br>&gt; marked as not compilable. There is an other flag which collects a lot more information (huge output file) about&nbsp;<br>&gt; compilation but it is for an other step if you want to investigate it further.<br>We will try to do such a test and check out the results. Unfortunately we haven't been able to recreate the issue in our test environment yet, we only have seen this in production.<br><br><div>&gt; I also change mail address to JIT compiler group since it is not GC discussion.<br></div><div>Thanks for that.</div><div><br></div><div>So far the test run that i have started with both flags turned on seems to be going fine and is not crashing. But that wouldn't mean it would not occur. We might try just increasing the code cache as a first step and then if the problem seems to reoccur would think of checking out the code cache flushing flag. Any ideas when that would get fixed?</div><div><br></div><div>Thank you very much,</div><div><br></div><div>Atul</div><div><br></div><div><div id="SkyDrivePlaceholder"></div>&gt; Date: Sat, 16 Jun 2012 16:21:54 -0700<br>&gt; From: vladimir.kozlov@oracle.com<br>&gt; To: atulksh@hotmail.com<br>&gt; CC: hotspot-compiler-dev@openjdk.java.net<br>&gt; Subject: Re: significant performance degradation seen after running application for few days with CMS collector and large heap size<br>&gt; <br>&gt; Hi, Atul<br>&gt; <br>&gt; I want to point that -XX:+UseCodeCacheFlushing flag in jdk 6 may also cause crashes, as other customers found. So your <br>&gt; only choice is increase CodeCache. There are several things happening which may cause your problem. C2 use "uncommon <br>&gt; traps" when compiles methods with a profile which shows that some paths in code were not executed before the compilation <br>&gt; time. A compiled code has also dependencies on loaded classes. All this leads to deoptimization and throwing out <br>&gt; previously compiled code if original compiling conditions are invalidated. After that a method re-executed in <br>&gt; Interpreter and recompiled again if it is still hot. There are cases when a method is recompiled a lot of times and <br>&gt; eventually C2 marks it as not compilable. Method could be marked as not compilable for other reasons also. Also at the <br>&gt; same time methods which executed less frequent get enough invocations to be compiled. Also we don't do CodeCache <br>&gt; compression which leads to fragmentation of free space. So I can imaging a situation when a very hot methods were <br>&gt; deoptimized but there were no space left for recompiled code.<br>&gt; <br>&gt; Increase CodeCache size and do some test runs with -XX:+PrintCompilation. Look for methods which compiled a lot times or <br>&gt; marked as not compilable. There is an other flag which collects a lot more information (huge output file) about <br>&gt; compilation but it is for an other step if you want to investigate it further.<br>&gt; <br>&gt; I also change mail address to JIT compiler group since it is not GC discussion.<br>&gt; <br>&gt; regards,<br>&gt; Vladimir<br>&gt; <br>&gt; On 6/16/12 12:45 PM, Atul Kshatriya wrote:<br>&gt; &gt; Hello Vladimir,<br>&gt; &gt; We seem to have very strong evidence that the slowness in our apps is caused by the code cache becoming full. We have<br>&gt; &gt; found that trolling the logs of our servers.<br>&gt; &gt;<br>&gt; &gt; We have kind of verified that if the compiler is turned off, typical operations in our app will take significantly<br>&gt; &gt; longer - this we proved by just setting the code cache to an extremely small amount triggering the compiler to be turned<br>&gt; &gt; off almost immediately on startup.<br>&gt; &gt;<br>&gt; &gt; What we haven't been able to fully understand is why this is happening (code cache becoming full) - since we do not seem<br>&gt; &gt; to have any dynamically loaded components (and unloading of them) in our app. It could be that we were just at the<br>&gt; &gt; threshold and that new feature additions has made the codebase big enough that we are hitting the max. But what could<br>&gt; &gt; explain the following: without flushing turned on, an operation runs fast first, but then once the code cache gets full,<br>&gt; &gt; after a few days starts getting slow. It is like for sometime the compiled code is cached, and runs fast, even after<br>&gt; &gt; code cache is full, but eventually it is "removed" and something else takes it's place. What I would have expected is<br>&gt; &gt; that once the code cache is full, what has already been compiled and running fast keeps running fast, and the new things<br>&gt; &gt; that get loaded would not be compiled and those would be slow. But that does not seem to be the case. This is still a<br>&gt; &gt; puzzle to us.<br>&gt; &gt;<br>&gt; &gt; Anyway we are running tests with increased code cache as well as flushing turned on to see if we see any ill effects. If<br>&gt; &gt; those pass we will be trying them out to see if they solve our problem. We are quite hopeful.<br>&gt; &gt;<br>&gt; &gt; Thank you so much so showing us the direction.<br>&gt; &gt;<br>&gt; &gt; -Atul<br>&gt; &gt;<br>&gt; &gt;  &gt; Date: Fri, 15 Jun 2012 11:42:05 -0700<br>&gt; &gt;  &gt; From: vladimir.kozlov@oracle.com<br>&gt; &gt;  &gt; To: atulksh@hotmail.com<br>&gt; &gt;  &gt; CC: hotspot-gc-dev@openjdk.java.net<br>&gt; &gt;  &gt; Subject: Re: significant performance degradation seen after running application for few days with CMS collector and<br>&gt; &gt; large heap size<br>&gt; &gt;  &gt;<br>&gt; &gt;  &gt; I forgot to say that 6u31 supports CodeCache cleanup when it is almost full:<br>&gt; &gt;  &gt;<br>&gt; &gt;  &gt; -XX:+UseCodeCacheFlushing<br>&gt; &gt;  &gt;<br>&gt; &gt;  &gt; So try it also if CodeCache is your problem (the flag is off by default in 6u31).<br>&gt; &gt;  &gt;<br>&gt; &gt;  &gt; Vladimir<br>&gt; &gt;  &gt;<br>&gt; &gt;  &gt; Vladimir Kozlov wrote:<br>&gt; &gt;  &gt; &gt; If it is not full GC, may be your code cache is full so JIT stop<br>&gt; &gt;  &gt; &gt; compiling and you start running in interpreter only. Look for next<br>&gt; &gt;  &gt; &gt; message in your output:<br>&gt; &gt;  &gt; &gt;<br>&gt; &gt;  &gt; &gt; CodeCache is full. Compiler has been disabled.<br>&gt; &gt;  &gt; &gt; Try increasing the code cache size using -XX:ReservedCodeCacheSize=<br>&gt; &gt;  &gt; &gt;<br>&gt; &gt;  &gt; &gt; The default is 48Mb for 6u31: -XX:ReservedCodeCacheSize=48m<br>&gt; &gt;  &gt; &gt;<br>&gt; &gt;  &gt; &gt; Vladimir<br>&gt; &gt;  &gt; &gt;<br>&gt; &gt;  &gt; &gt; Atul Kshatriya wrote:<br>&gt; &gt;  &gt; &gt;&gt; Hello,<br>&gt; &gt;  &gt; &gt;&gt; We have a Tomcat based java server application configured to use the<br>&gt; &gt;  &gt; &gt;&gt; CMS collector. We have a relatively large heap - anywhere from 23Gb to<br>&gt; &gt;  &gt; &gt;&gt; upto 58Gb. What we are seeing is that after the application runs for a<br>&gt; &gt;  &gt; &gt;&gt; week or two, a request that would normally take few seconds takes tens<br>&gt; &gt;  &gt; &gt;&gt; of seconds to complete. This manifests itself as users seeing<br>&gt; &gt;  &gt; &gt;&gt; extremely slow performance from the server.<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; We have looked at the gc logs and they do not seem to show any<br>&gt; &gt;  &gt; &gt;&gt; significant increase in pause times. We have made sure that the server<br>&gt; &gt;  &gt; &gt;&gt; is not loaded (load average is pretty minimal) and there is no other<br>&gt; &gt;  &gt; &gt;&gt; process running that would affect the server.<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; If the application is restarted then we again get good performance<br>&gt; &gt;  &gt; &gt;&gt; until after a few days the performance deteriorates. Once that happens<br>&gt; &gt;  &gt; &gt;&gt; it does not seem to go back down again and stays at that level.<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; The platform we are using is 64 bit x86 running SUSE (SUSE Linux<br>&gt; &gt;  &gt; &gt;&gt; Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 0).<br>&gt; &gt;  &gt; &gt;&gt; The JDK we are using is JEK 1.6 Update 31.<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; The parameters we are using for the jvm are as follows:<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; -Xmx58G -Xms58G -server<br>&gt; &gt;  &gt; &gt;&gt; -XX:PermSize=256m -XX:MaxPermSize=256m<br>&gt; &gt;  &gt; &gt;&gt; -XX:+ExplicitGCInvokesConcurrent -XX:+UseConcMarkSweepGC<br>&gt; &gt;  &gt; &gt;&gt; -XX:+PrintGCDetails -XX:+PrintGCTimeStamps<br>&gt; &gt;  &gt; &gt;&gt; -XX:CMSInitiatingOccupancyFraction=70<br>&gt; &gt;  &gt; &gt;&gt; -XX:-CMSConcurrentMTEnabled -XX:+UseCompressedOops<br>&gt; &gt;  &gt; &gt;&gt; -XX:ObjectAlignmentInBytes=16<br>&gt; &gt;  &gt; &gt;&gt; -XX:+PrintTenuringDistribution -XX:PrintCMSStatistics=2<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; We suspect this is something to do with the CMS garbage collect but<br>&gt; &gt;  &gt; &gt;&gt; have not been able to identify what exactly it might be looking at the<br>&gt; &gt;  &gt; &gt;&gt; gc logs. Has anybody seen such a behavior and any possible suspects<br>&gt; &gt;  &gt; &gt;&gt; like memory fragmentation etc.<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; Any help regarding this greatly appreciated.<br>&gt; &gt;  &gt; &gt;&gt;<br>&gt; &gt;  &gt; &gt;&gt; -Atul<br></div></div>                                               </div></body>
</html>