<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi all,<div><br></div><div>I started an email this morning trying to outline why iCMS is better than CMS but I then needed to start presenting my performance tuning seminar. I'll start again and kill the draft. So to Ramki's request, the simple reason is that by having iCMS run it keeps memory cleaner and so they never run into situations where they experience very long pause times. With CMS they always ran into a situation where the pause times exceed response time requirements (large trading application). This was but one use case. Unfortunately I only have production iCMS logs from this client. I've also received (via my send me your GC log program) a number of other logs from people with similar low latency requirements. I must say that I was quite frankly surprised to iCMS showing up in in the logs and that it was being used in so many places. That said, the results were also surprisingly very good given that this use case (24 cores, 32g heap) runs counter to original intent. But then I've seen a number of "odd ball" CMS configurations that also make sense in hindsight.</div><div><br></div><div>As for a reference app... very difficult to come up with... I've been picking at "reference" apps for a while.. and the problem is.. as soon as I get a good one.. you guys to something in the JVM that suddenly makes it very disappointing to use the app for a performance tuning demonstration. So, instead of answering Ramki, I had to de-tune one of my reference apps that was running perfectly horribly until I started using 1.7.0_05... Can I ask that you all to please STOP DOING THAT ;-) .... stop making it harder to de-tune my reference app!!!!</div><div><br></div><div>Seriously, the biggest problem that I see right now is adaptive sizing. The default parallel collector combination works brilliantly except that adaptive sizing leaves survivor spaces undersized. This undersizing often leads to increase frequency of full collections. I'm very much interested in looking at how this might be corrected.</div><div><br></div><div>-- Kirk</div><div><br><div><div>On 2012-12-06, at 2:23 PM, Bengt Rutisson <<a href="mailto:bengt.rutisson@oracle.com">bengt.rutisson@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
Hi Kirk and Ramki,<br>
<br>
On 12/6/12 12:05 AM, Srinivas Ramakrishna wrote:<br>
</div>
<blockquote cite="mid:CABzyjyn2tv6CrhLxxFatT5wd6eH0uj0kocLxkk0h9G0tJ+zcmw@mail.gmail.com" type="cite">I am thinking that if we have a "test case" or
publicly available application that can serve as a "witness" to
this, it would<br>
allow us to learn a few useful things on how regular CMS might do
better for such apps, and understand the basis of<br>
this difference. (Unless you have already analysed it and can
share your summary of it.)<br>
</blockquote>
<br>
Yes, I totally agree with this. If there are cases where i-CMS is
better than regular CMS we need to understand why and should try to
get CMS to perform as well (or better). This is a much more
appealing solution to me than to keep the extra complexity that
i-CMS introduces.<br>
<br>
Kirk, if you have log files of runs with CMS and i-CMS it would be
great if you can pass them along. I would be very interested in
analyzing why i-CMS would preform better than CMS.<br>
<br>
Thanks,<br>
Bengt<br>
<br>
<blockquote cite="mid:CABzyjyn2tv6CrhLxxFatT5wd6eH0uj0kocLxkk0h9G0tJ+zcmw@mail.gmail.com" type="cite"><br>
thanks!<br>
-- ramki<br>
<br>
<div class="gmail_quote">On Wed, Dec 5, 2012 at 3:01 PM, Srinivas
Ramakrishna <span dir="ltr"><<a moz-do-not-send="true" href="mailto:ysr1729@gmail.com" target="_blank">ysr1729@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kirk --<br>
<br>
<div class="gmail_quote">
<div class="im">On Wed, Dec 5, 2012 at 2:48 PM, Kirk
Pepperdine <span dir="ltr"><<a moz-do-not-send="true" href="mailto:kirk@kodewerk.com" target="_blank">kirk@kodewerk.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
<br>
The JEP's are coming in fast and furious. There is a
customer use case for iCMS.. it's used by low latency
applications... and quite successfully in fact. iCMS
manages large heaps much better than CMS does which
translates into more manageable pause times... I've got
logs from a number of customers that rely on iCMS.<br>
</blockquote>
</div>
<div><br>
This is very interesting indeed (and something i had
vaguely heard a few years ago from the general grapevine,
although never actually understood<br>
why it must be so). Could you go a bit deeper on why this
is so? What exactly is it about doing a "slow, spread-out,
incremental CMS collection"<br>
that makes it work better than bang-bang vanilla CMS in
large multi-core, server environments? Perhaps the
insights from that might translate into<br>
something useful for vanilla CMS?<br>
<br>
Your experience does indicate that we must proceed with
some caution here before we deprecate iCMS, given it might
still have some useful life<br>
(notwithstanding my own instincts to the contrary -- in
server environments -- expressed in an earlier email
before I had seen yours).<br>
<br>
thanks.<br>
-- ramki<br>
<br>
</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Kirk<br>
<div>
<div><br>
<br>
On 2012-12-05, at 11:10 PM, <a moz-do-not-send="true" href="mailto:mark.reinhold@oracle.com" target="_blank">mark.reinhold@oracle.com</a>
wrote:<br>
<br>
> Posted: <a moz-do-not-send="true" href="http://openjdk.java.net/jeps/173" target="_blank">http://openjdk.java.net/jeps/173</a><br>
><br>
> - Mark<br>
<br>
</div>
</div>
</blockquote>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</blockquote></div><br></div></body></html>