strange gc log

Y. S. Ramakrishna y.s.ramakrishna at
Wed Sep 8 15:59:20 UTC 2010

Thanks; I'll take a look at yr more complete log and see if it sheds
further light on the problem.

-- ramki

On 09/07/10 18:22, BlueDavy Lin wrote:
> The more complete log is attached.
> I can understand the full gc when concurrent mode failure,but I'm not
> understand why the below full gc occurs,such as:
> 2010-09-05T14:11:50.853+0800: 433.517: [GC 433.517: [ParNew:
> 2321294K->174080K(2403008K), 0.0337420 secs]
> 2999673K->855426K(3975872K), 0.0340840 secs] [Times: user=0.11
> sys=0.00, real=0.04 secs]
> 2010-09-05T14:12:09.941+0800: 452.604: [Full GC 452.604: [CMS:
> 681345K->669781K(1572864K), 3.0214780 secs]
> 2485669K->669781K(3975872K), [CMS Perm : 94825K->94800K(262144K)],
> 3.0217260 secs] [Times: user=3.03 sys=0.00, real=3.03 secs]
> From the log,I think even if I decrease the
> CMSInitiatingOccupancyFraction,it'll cause the cms gc more
> frequency,and cannot work for current situation.
> ps: this is a gc presentation I wrote for my company,if somebody are
> interested in it,u can see it from this url:
> 2010/9/8 Y. S. Ramakrishna <y.s.ramakrishna at>:
>> Do you have a longer/more complete GC log, or is
>> this all of the log you have?
>> It is possible that you have some rather large objects that
>> survive for a short while and then die. This seems to be fragmenting
>> the old generation quite considerably. Did you try to use a heap
>> say twice as large to see if the behaviour is any better?
>> Running with -XX:PrintFLSStatistics=1 -XX:PrintCMSStatistics=1
>> -XX:+PrintHeapAtGC
>> might provide a bit more information.
>> (PS: can you send the log file as an attachment, so that your
>> editor does not insert line-breaks into the log file?)
>> -- ramki

More information about the hotspot-gc-dev mailing list