MaxTenuringThreshold available in ParNewGC?

[Li Li]

yesterday, we set the maxNewSize to 256mb. And it works as we expected. but
an hours ago, there is a promotion failure and a concurrent mode failure
which cost 14s!  could anyone explain the gc logs for me?
or any documents for the gc log format explanation?

1. Desired survivor size 3342336 bytes, new threshold 5 (max 5)
   it says survivor size is 3mb
2. 58282K->57602K(59072K), 0.0543930 secs]
   it says before young gc the memory used is 58282K, after young gc, there
are 57602K live objects and the total young space is 59072K
3. (concurrent mode failure): 7907405K->3086848K(7929856K), 14.3005340
secs] 7961046K->3086848K(7988928K), [CMS Perm : 32296K->31852K(53932K)],
14.3552450 secs] [Times: user=14.53 sys=0.01, real=14.35 secs]
     before old gc, 7.9GB is used. after old gc 3GB is alive. total old
space is 7.9GB

in which situation will occur promotion failure and concurrent mode failure?
from
http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/
the author says when CMS is doing concurrent work and JVM is asked for more
memory. if there isn't any space for new allocation. then it will occur
concurrent mode failure and it will stop the world and do a serial old gc.
if there exist enough space but they are fragemented, then a promotion
failure will occur.
am I right?

2012-01-12T18:27:32.582+0800: [GC [ParNew
Desired survivor size 3342336 bytes, new threshold 1 (max 5)
- age   1:    4594648 bytes,    4594648 total
- age   2:     569200 bytes,    5163848 total
: 58548K->5738K(59072K), 0.0159400 secs] 7958648K->7908502K(7984352K),
0.0160610 secs] [Times: user=0.17 sys=0.00, real=0.02 secs]
2012-01-12T18:27:32.609+0800: [GC [ParNew (promotion failed)
Desired survivor size 3342336 bytes, new threshold 5 (max 5)
- age   1:    1666376 bytes,    1666376 total
: 58282K->57602K(59072K), 0.0543930 secs][CMS2012-01-12T18:27:33.804+0800:
[CMS-concurrent-preclean: 14.098/34.323 secs] [Times: user=370.28 sys=5.65,
real=34.31 secs]
 (concurrent mode failure): 7907405K->3086848K(7929856K), 14.3005340 secs]
7961046K->3086848K(7988928K), [CMS Perm : 32296K->31852K(53932K)],
14.3552450 secs] [Times: user=14.53 sys=0.01, real=14.35 secs]

On Wed, Jan 11, 2012 at 5:48 PM, Kirk Pepperdine
<kirk.pepperdine at gmail.com>wrote:

> CMS is not adaptive. To reconfigure heap, for many reasons, you need a
> full GC to occur. The response to a concurrent mode failure is always a
> full GC. That gave the JVM the opportunity to resize heap space. If this
> behaviour isn't happening when it should or is cause other problems it's
> time to either set the young gen size directly with NewSize or switch to
> the parallel collector with the adaptive sizing policy turned on. Logic
> here is that you want to avoid long pauses, use CMS. If CMS is giving you
> long pauses, than the parallel collector might be a better choice.
>
> Regards,
> Kirk
>
> On 2012-01-11, at 10:32 AM, Li Li wrote:
>
> > after a concurrent mode failure. the young generation changed from about
> 50MB to 1.8GB
> > What's the logic behind this?
> >
> > 2012-01-10T22:23:54.544+0800: [GC [ParNew: 55389K->6528K(59072K),
> 0.0175440 secs] 5886124K->5839323K(6195204K), 0.0177480 secs] [Times:
> user=0.20 sys=0.00, real=0.01 secs]
> > 2012-01-10T22:23:54.575+0800: [GC [ParNew: 59072K->6528K(59072K),
> 0.0234040 secs] 5891867K->5845823K(6201540K), 0.0236070 secs] [Times:
> user=0.24 sys=0.00, real=0.02 secs]
> > 2012-01-10T22:23:54.612+0800: [GC [ParNew (promotion failed):
> 59072K->58862K(59072K), 2.3119860 secs][CMS2012-01-10T22:23:57.153+0800:
> [CMS-concurrent-preclean: 10.999/28.245 secs] [Times: user=290.41 sys=4.65,
> real=28.24 secs]
> >  (concurrent mode failure): 5841457K->2063142K(6144000K), 8.8971660
> secs] 5898367K->2063142K(6203072K), [CMS Perm : 31369K->31131K(52316K)],
> 11.2110080 secs] [Times: user=11.73 sys=0.51, real=11.21 secs]
> > 2012-01-10T22:24:06.125+0800: [GC [ParNew: 1638400K->46121K(1843200K),
> 0.0225800 secs] 3701542K->2109263K(7987200K), 0.0228190 secs] [Times:
> user=0.26 sys=0.02, real=0.02 secs]
> > 2012-01-10T22:24:06.357+0800: [GC [ParNew: 1684521K->111262K(1843200K),
> 0.0381370 secs] 3747663K->2174404K(7987200K), 0.0383860 secs] [Times:
> user=0.44 sys=0.04, real=0.04 secs]
> >
> > _______________________________________________
> > hotspot-gc-use mailing list
> > hotspot-gc-use at openjdk.java.net
> > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120112/586eb629/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use