CMS GC tuning under JVM 5.0

Y Srinivas Ramakrishna Y.S.Ramakrishna at Sun.COM
Fri Apr 18 19:24:09 PDT 2008


Here you go:-

http://bugs.sun.com/view_bug.do?bug_id=6538910

It shows up as fixed in 5u16b01 according to the bug report.
Also documented is the workaround.

If you have issues with long remark pauses when you use the
workaround, refer to CR http://bugs.sun.com/view_bug.do?bug_id=6572569

-- ramki

----- Original Message -----
From: Y Srinivas Ramakrishna <Y.S.Ramakrishna at Sun.COM>
Date: Friday, April 18, 2008 7:15 pm
Subject: Re: CMS GC tuning under JVM 5.0
To: Thomas Viessmann <Thomas.Viessmann at Sun.COM>
Cc: "Jones, Doug H" <doug.jones at EDS.COM>, hotspot-gc-use at openjdk.java.net


> > > 31680.017: [CMS-concurrent-mark: 0.477/0.477 secs]
> 
> > > 31680.023: [CMS-concurrent-preclean: 0.006/0.006 secs]
> 
> > > secs]31768.430: [CMS31768.430: [CMS-concurrent-abortable-preclean: 
> 
> > > 5.410/88.406 secs]
> 
> > > 100080.381: [CMS-concurrent-mark: 0.494/0.494 secs]
> 
> > > 100080.390: [CMS-concurrent-preclean: 0.009/0.009 secs]
> 
> > > secs]100259.694: [CMS100259.695: 
> [CMS-concurrent-abortable-preclean: 
> > 
> > > 10.649/179.305 sec
> > >
> > > s]
> 
> Just to add a bit to what Jon said, the notation [CMS-concurrent-xxx:  
> yyy/zzz secs]
> indicates that the CMS concurrent xxx-phase took roughly zzz secs of wall-clock
> elapsed time, of which yyy secs of accumulated elapsed time was spent 
> by the
> CMS thread doing that work; the remainder of the time, zzz - yyy secs, 
> the
> thread was either sleeping or was stalled for a lock. Note that yyy 
> secs is
> a rough upper bound of the lwp-virtual time, but the thread need not necessarily
> have been on-proc all of that time.
> 
> So in particular, in the last display, of the 179 secs of elapsed time 
> the CMS thread
> was actually sleeping for 169 secs. Jon's conjecture of the bug about 
> CMSMaxAbortablePrecleanTime
> seems to be the most likely explanation. (There was a confusion with 
> the interpretation
> of the units, treating an intended ms spec as a seconds spec, the documented
> workaround is to set the value to a value in seconds not exceeding 
> about 5:
> -XX:CMSMaxAbortablePrecleanTime=5 -- or to zero to just elide that phase.)
> 
> I believe this has been fixed in some later version of JDK 5uXX, but 
> am unable to
> check the bug id at the moment.
> 
> -- ramki
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use



More information about the hotspot-gc-use mailing list