
<HTML dir=ltr><HEAD><TITLE>Re: CMS GC tuning under JVM 5.0</TITLE>

<META http-equiv=Content-Type content="text/html; charset=unicode">

<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>

<BODY>

<DIV id=idOWAReplyText40143 dir=ltr>

<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Hi Ramki, and Jon,</FONT></DIV>

<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>Thank you for the background information - indeed the bug would appear to explain exactly what we are seeing in terms of long times for the concurrent-abortable-preclean phase. The application is using 5u08 so it would be present.</FONT></DIV>

<DIV dir=ltr> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>So just to summarize for anybody else's general information if they happen to come across an application which has similar characteristics (ie has normal steady-state processing, but also has periodic spurts of very much greater activity, which the Collector is not easily able to adapt or respond to), under a JDK 5.0 version prior to u16, what we will try is:</FONT></DIV>

<DIV dir=ltr> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>1) Set CMSInitiatingOccupancyFraction to a value so that the tenured area contains at least twice NewSize when it reaches this percent full, AND set +UseCMSInitiatingOccupancyOnly so that the Collector honours this value (ie disabling its default 'JIT plus a bit to be safe' behaviour)</FONT></DIV>

<DIV dir=ltr> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>2) Specifically set CMSMaxAbortablePrecleanTime=5 so the concurrent-abortable-preclean phase max time is correctly interpreted under this version as 5 seconds (the 6.0 default value), and</FONT></DIV>

<DIV dir=ltr> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>3) As suggested in the second bug mentioned by Ramki, we may also set +CMSScavengeBeforeRemak. This flag is I believe not on by default in any current JDK version, but in our case with a relatively small NewSize, a ParNew collection takes max something like 0.02sec (and that's when at its full 24Mb) so should add virtually nothing to the time the app is stopped.</FONT></DIV>

<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>Actually from looking at other CMS Collections in the same log, just 1) and 3) on their own may fix the problem because we see several examples where the CMS GC has kicked in with eden containing less than 1Mb and the abortable-preclean phase is omitted altogether. However this is specific to the characteristics of our application. I have no doubt that there are other situations where setting CMSScavengeBeforeRemak is not desirable.</FONT></DIV>

<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>Again thanks everyone for your assistance,</FONT></DIV>

<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>

<DIV dir=ltr><FONT face=Arial size=2>Doug.</FONT></DIV>

<DIV dir=ltr><BR>

<HR tabIndex=-1>

<FONT face=Tahoma size=2><B>From:</B> hotspot-gc-use-bounces@openjdk.java.net on behalf of Y Srinivas Ramakrishna<BR><B>Sent:</B> Sat 19/04/2008 2:24 p.m.<BR><B>To:</B> Y Srinivas Ramakrishna<BR><B>Cc:</B> Jones, Doug H; hotspot-gc-use@openjdk.java.net; Thomas Viessmann<BR><B>Subject:</B> Re: CMS GC tuning under JVM 5.0<BR></FONT><BR></DIV></DIV>

<DIV>

<P><FONT size=2>Here you go:-<BR><BR><A href="http://bugs.sun.com/view_bug.do?bug_id=6538910">http://bugs.sun.com/view_bug.do?bug_id=6538910</A><BR><BR>It shows up as fixed in 5u16b01 according to the bug report.<BR>Also documented is the workaround.<BR><BR>If you have issues with long remark pauses when you use the<BR>workaround, refer to CR <A href="http://bugs.sun.com/view_bug.do?bug_id=6572569">http://bugs.sun.com/view_bug.do?bug_id=6572569</A><BR><BR>-- ramki<BR><BR>----- Original Message -----<BR>From: Y Srinivas Ramakrishna <Y.S.Ramakrishna@Sun.COM><BR>Date: Friday, April 18, 2008 7:15 pm<BR>Subject: Re: CMS GC tuning under JVM 5.0<BR>To: Thomas Viessmann <Thomas.Viessmann@Sun.COM><BR>Cc: "Jones, Doug H" <doug.jones@EDS.COM>, hotspot-gc-use@openjdk.java.net<BR><BR><BR>> > > 31680.017: [CMS-concurrent-mark: 0.477/0.477 secs]<BR>><BR>> > > 31680.023: [CMS-concurrent-preclean: 0.006/0.006 secs]<BR>><BR>> > > secs]31768.430: [CMS31768.430: [CMS-concurrent-abortable-preclean:<BR>><BR>> > > 5.410/88.406 secs]<BR>><BR>> > > 100080.381: [CMS-concurrent-mark: 0.494/0.494 secs]<BR>><BR>> > > 100080.390: [CMS-concurrent-preclean: 0.009/0.009 secs]<BR>><BR>> > > secs]100259.694: [CMS100259.695:<BR>> [CMS-concurrent-abortable-preclean:<BR>> ><BR>> > > 10.649/179.305 sec<BR>> > ><BR>> > > s]<BR>><BR>> Just to add a bit to what Jon said, the notation [CMS-concurrent-xxx: <BR>> yyy/zzz secs]<BR>> indicates that the CMS concurrent xxx-phase took roughly zzz secs of wall-clock<BR>> elapsed time, of which yyy secs of accumulated elapsed time was spent<BR>> by the<BR>> CMS thread doing that work; the remainder of the time, zzz - yyy secs,<BR>> the<BR>> thread was either sleeping or was stalled for a lock. Note that yyy<BR>> secs is<BR>> a rough upper bound of the lwp-virtual time, but the thread need not necessarily<BR>> have been on-proc all of that time.<BR>><BR>> So in particular, in the last display, of the 179 secs of elapsed time<BR>> the CMS thread<BR>> was actually sleeping for 169 secs. Jon's conjecture of the bug about<BR>> CMSMaxAbortablePrecleanTime<BR>> seems to be the most likely explanation. (There was a confusion with<BR>> the interpretation<BR>> of the units, treating an intended ms spec as a seconds spec, the documented<BR>> workaround is to set the value to a value in seconds not exceeding<BR>> about 5:<BR>> -XX:CMSMaxAbortablePrecleanTime=5 -- or to zero to just elide that phase.)<BR>><BR>> I believe this has been fixed in some later version of JDK 5uXX, but<BR>> am unable to<BR>> check the bug id at the moment.<BR>><BR>> -- ramki<BR>> _______________________________________________<BR>> hotspot-gc-use mailing list<BR>> hotspot-gc-use@openjdk.java.net<BR>> <A href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</A><BR>_______________________________________________<BR>hotspot-gc-use mailing list<BR>hotspot-gc-use@openjdk.java.net<BR><A href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</A><BR></FONT></P></DIV></BODY></HTML>