<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Alexey,<br>
<br>
A factor of 2 improvement on large heaps is impressive but something<br>
more modest on small heaps would be welcome and I wondered whether<br>
it was worth trying to do 8 bytes rows on a 32 bit system. The
current<br>
implementation does 4 bytes rows on a 32 bit system, correct?<br>
<br>
Jon<br>
<br>
On 02/27/12 07:31, Alexey Ragozin wrote:
<blockquote
cite="mid:CAMgTVm+j4qPd6OgxiF4F_URJ8DCGFnZQ7eotH2asXX4Z39JHJQ@mail.gmail.com"
type="cite">Hi Jon,<br>
<br>
Bengt has ran patch trough JPRT, so it should cover 32 bit
systems. I havn't done any specific testing to 32 system.<br>
Reason is that for small heaps, dirty cards are more dense and
scanning heap is taking order of magnitude more time than card
table scanning.<br>
<br>
Practical impact of patch is starting to show up with heaps around
8GiB (30GiB was upper limit for my research) thus making 32 bit
JVM not very interesting.<br>
<br>
Regards,<br>
Alexey<br>
<br>
<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Jon Masamitsu <<a moz-do-not-send="true"
href="mailto:jon.masamitsu@oracle.com">jon.masamitsu@oracle.com</a>><br>
Subject: Re: Fwd: (resend) Request for review (S): 7068625
Testing 8<br>
bytes of card table entries at a time speeds up
card-scanning<br>
To: <a moz-do-not-send="true"
href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a><br>
Message-ID: <<a moz-do-not-send="true"
href="mailto:4F47E7B7.6090407@oracle.com">4F47E7B7.6090407@oracle.com</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
Alexey,<br>
<br>
Change looks good.<br>
<br>
Did you run the tests on 32bit and smaller heaps (~4G)?<br>
That would give you 4byte rows (instead of 8byte rows),<br>
right?<br>
<br>
Jon<br>
<br>
On 2/24/2012 4:14 AM, Bengt Rutisson wrote:<br>
><br>
> Hi all,<br>
><br>
> Just pinging this review request. Does anybody have some
time to look<br>
> at it? It is a fairly small and straight forward
change...<br>
><br>
> Thanks,<br>
> Bengt<br>
><br>
> -------- Original Message --------<br>
> Subject: Request for review (S): 7068625 Testing 8
bytes of card<br>
> table entries at a time speeds up card-scanning<br>
> Date: Tue, 21 Feb 2012 12:03:50 +0400<br>
> From: Alexey Ragozin <<a moz-do-not-send="true"
href="mailto:alexey.ragozin@gmail.com">alexey.ragozin@gmail.com</a>><br>
> To: <a moz-do-not-send="true"
href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a><br>
> CC: Bengt Rutisson <<a moz-do-not-send="true"
href="mailto:bengt.rutisson@oracle.com">bengt.rutisson@oracle.com</a>><br>
><br>
><br>
><br>
> Hi,<br>
><br>
> I would like few volunteers to review changes for<br>
> <a moz-do-not-send="true"
href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625"
target="_blank">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625</a><br>
> WebRev: <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Ebrutisso/7068625/webrev.00/"
target="_blank">http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/</a><br>
> <<a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Ebrutisso/7068625/webrev.00/"
target="_blank">http://cr.openjdk.java.net/%7Ebrutisso/7068625/webrev.00/</a>><br>
><br>
> Change summary<br>
> For large heaps (I was focusing on 8GiB and above) it is
common to<br>
> have long continuous ranges of clean cards.<br>
> Patch is introducing a short path for skipping ranges of
clean cards<br>
> using word aligned memory access instead of byte aligned.<br>
><br>
> Patch affects serial and CMS collectors. For CMS
collector stride size<br>
> should be increase to see any performance gains (I was
using<br>
> -XX:+UnlockDiagnosticVMOptions<br>
> -XX:ParGCCardsPerStrideChunk=4096)<br>
><br>
> For testing I was mainly using synthetic benchmark
randomly modifying<br>
> hash tables in heap, thus uniformly touching cards across
heaps.<br>
> Average duration of young GC pause were used as KPI.<br>
> More details about testing can be found at<br>
> <a moz-do-not-send="true"
href="http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html"
target="_blank">http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html</a><br>
> Though article is referring jdk6, my resent tests with
trunk jdk7 show<br>
> no difference.<br>
> I was also tested patch with real application (Oracle
Coherence<br>
> storage node).<br>
> With 16GiB of heap and CMS/ParNew GC, enabling patch have
shortened GC<br>
> pauses roughly in 2 times.<br>
><br>
> Source code of benchmark used in test are available at<br>
> <a moz-do-not-send="true"
href="https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench"
target="_blank">https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench</a><br>
><br>
> Main class YoungGCPauseBenchmark<br>
><br>
> Regards,<br>
> Alexey<br>
><br>
><br>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>