<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000099">
<blockquote>Chi Ho Kwok, hi<br>
<br>
I can confirm the following:<br>
<br>
1) I followed Ramki advice below and deployed JDK 7 b83 with HS17;<br>
<br>
2) it does stop crashes in G1 which were happening in JDK 6 u18 HS16;<br>
<br>
3) but G1 cpu usage is like 10 times more then CMS under same load,<br>
and cpu load pattern is excessively spikey in G1, while much more
smooth in CMS;<br>
<br>
4) G1 pauses are 200 ms, while CMS pauses are 50 ms under same load;<br>
<br>
5) I am using the following ergonomic options:<br>
-XX:MaxGCPauseMillis=70<br>
-XX:GCPauseIntervalMillis=700<br>
<br>
6) per gc logs, most of G1 200 ms pause is spent in "Remembered Set
Rescan"<br>
this is presumably because this "helpful ergonomics" can not separate<br>
static heap set and keeps scanning it all the time;<br>
<br>
any advice how to kill this ergonomics and provide manual overrides is
much appreciated!<br>
<br>
thank you<br>
<br>
Andrei<br>
<br>
</blockquote>
<br>
-------- Original Message --------<br>
Subject: Re: G1 is bad for me<br>
From: Chi Ho Kwok <a class="moz-txt-link-rfc2396E" href="mailto:chkwok@digibites.nl"><chkwok@digibites.nl></a><br>
To: hotspot-gc-use <a class="moz-txt-link-rfc2396E" href="mailto:hotspot-gc-use@openjdk.java.net"><hotspot-gc-use@openjdk.java.net></a><br>
Date: Fri 19 Feb 2010 08:59:53 AM CST<br>
<blockquote
cite="mid:1b9d6f691002190659i6917bdafo2d61a4f59a833f41@mail.gmail.com"
type="cite">
<div>Hi all,</div>
<div><br>
</div>
A large part of our CPU load is caused by GC, so I'm always interested
in new techniques, but the last time I tried G1 (6u14?), the jvm
rapidly crashed after startup under load. Is the recommendation to
switch to/wait for JDK7 releases for G1, or is G1 on 6u18 (or later?)
any good for production usage? I'd assume there will be more updates
for JDK6 as JDK7 got extended to up to 10 milestones.
<div><br>
</div>
<div>CMS with a 32G heap which changes rapidly (~10%/min replaced) is
manageable, but we're "losing" 20% capacity because the threshold has
to be so low, anything higher than 80% causes new gen promotions to
fail during CMS and the app to stop for half a minute. Processing
capacity is also reduced by half during a CMS run because the amount of
threads has to be high (=6 at the moment) to make it hurry up, or it'll
mean either setting the threshold even lower or risk promotion failures
:(</div>
<div><br>
</div>
<div>Chi Ho Kwok<br>
<div><br>
<div>
<div class="gmail_quote">On Thu, Feb 18, 2010 at 6:37 PM, Y. Srinivas
Ramakrishna <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Y.S.Ramakrishna@sun.com">Y.S.Ramakrishna@sun.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi
Andrei -- please use the latest hs17 JVM which you can get from JDK 7.
There have been<br>
many improvements (and bug fixes) since the 6u18/hs16 that you are
using below.<br>
Most importantly, please add -XX:-ReduceInitialCardMarks to work around
a regression<br>
introduced in 6u18/hs16, as described in the 6u18 release notes.<br>
As re optimal settings (these may be quite different from shapes that
helped with CMS<br>
for example), i'll let others w/more (tuning and other) experience w/G1
comment.<br>
<br>
-- ramki</blockquote>
</div>
</div>
</div>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
hotspot-gc-use mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a>
</pre>
</blockquote>
<br>
</body>
</html>