Hi Jon,<div><br></div><div>It might be helpful to set -XX:PrintFLSStatistics to a value greater than zero, to get the stats of FreeListSpace so that you'd know the size of the biggest fragment. The GC log produced by -XX:+PrintGCDetails doesn't give enough information on fragmentation.</div>
<div><br></div><div>Here's an example of using -XX:PrintFLSStatistics=1: <a href="https://gist.github.com/1329783">https://gist.github.com/1329783</a></div><div>It does make the GC log messier, and some of the GC log parsing tools won't cope with this, but you get to know how bad the fragmentation is.</div>
<div><br></div><div>Anyway, it looks like you're using CMS in incremental mode. This mode should be obsolete in JDK6 already. Is there a good reason for you to be using it? If not, I'd suggest turning it off, though, no matter if you're upgrading your JDK or not.</div>
<div><br></div><div>Regards,</div><div>Kris Mok</div><div><br><div class="gmail_quote">On Mon, Oct 31, 2011 at 9:06 PM, Jon Bright <span dir="ltr"><<a href="mailto:jon@siliconcircus.com">jon@siliconcircus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
We have an application running with a 6GB heap (complete parameters below).  Mostly it has a fairly low turnover of memory use, but on occasion, it will come under some pressure as it reloads a large in-memory data set from a database.<br>

<br>
Sometimes in this situation, we'll see a concurrent mode failure. Here's one failure:<br>
<br>
20021.464: [GC 20021.465: [ParNew: 13093K->3939K(76672K), 0.0569240 secs]20021.522: [CMS20023.747: [CMS-concurrent-mark: 11.403/29.029 secs] [Times: user=41.11 sys=1.03, real=29.03 secs]<br>
 (concurrent mode failure): 3873922K->2801744K(6206272K), 30.7900180 secs] 3886215K->2801744K(6282944K), [CMS Perm : 142884K->142834K(524288K)] icms_dc=33 , 30.8473830 secs] [Times: user=30.26 sys=0.71, real=30.85 secs]<br>

Total time for which application threads were stopped: 30.8484460 seconds<br>
<br>
(I've attached a lengthier log including the previous and subsequent CMS collection.)<br>
<br>
Am I correct in thinking that this failure can basically only be caused by fragmentation?  Both young and old seem to have plenty of space. There doesn't seem to be any sign that the tenured generation would run out of space before CMS completes.  Fragmentation is the only remaining cause that occurs to me.<br>

<br>
We're running with 1.6.0_11, although this will be upgraded to 1.6.0_26 tomorrow.  I realise our current version is ancient - I'm not really looking for help on the problem itself, just for advice on whether the log line above indicates fragmentation.<br>

<br>
Thanks<br>
<br>
Jon Bright<br>
<br>
<br>
<br>
The parameters we have set are:<br>
<br>
-server<br>
-Xmx6144M<br>
-Xms6144M<br>
-XX:MaxPermSize=512m<br>
-XX:PermSize=512m<br>
-XX:+UseConcMarkSweepGC<br>
-XX:+CMSIncrementalMode<br>
-XX:+CMSIncrementalPacing<br>
-XX:SoftRefLRUPolicyMSPerMB=3<br>
-XX:<u></u>CMSIncrementalSafetyFactor=30<br>
-XX:+PrintGCDetails<br>
-XX:+<u></u>PrintGCApplicationStoppedTime<br>
-XX:+<u></u>PrintGCApplicationConcurrentTi<u></u>me<br>
-XX:+PrintGCTimeStamps<br>
-Xloggc:/home/tbmx/log/gc_`<u></u>date +%Y%m%d%H%M`.log<br>
<br>
<br>_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
<br></blockquote></div><br></div>