Fwd: (resend) Request for review (S): 7068625 Testing 8 bytes of card table entries at a time speeds up card-scanning

Jon Masamitsu jon.masamitsu at oracle.com
Mon Feb 27 10:41:17 PST 2012


Alexey,

A factor of 2 improvement on large heaps is impressive but something
more modest on small heaps would be welcome and I wondered whether
it was worth trying to do 8 bytes rows on a 32 bit system.  The current
implementation does 4 bytes rows on a 32 bit system, correct?

Jon

On 02/27/12 07:31, Alexey Ragozin wrote:
> Hi Jon,
>
> Bengt has ran patch trough JPRT, so it should cover 32 bit systems. I 
> havn't done any specific testing to 32 system.
> 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.
>
> 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.
>
> Regards,
> Alexey
>
>
>     From: Jon Masamitsu <jon.masamitsu at oracle.com
>     <mailto:jon.masamitsu at oracle.com>>
>     Subject: Re: Fwd: (resend) Request for review (S): 7068625 Testing 8
>            bytes   of card table entries at a time speeds up card-scanning
>     To: hotspot-gc-dev at openjdk.java.net
>     <mailto:hotspot-gc-dev at openjdk.java.net>
>     Message-ID: <4F47E7B7.6090407 at oracle.com
>     <mailto:4F47E7B7.6090407 at oracle.com>>
>     Content-Type: text/plain; charset=UTF-8; format=flowed
>
>     Alexey,
>
>     Change looks good.
>
>     Did you run the tests on 32bit and smaller heaps (~4G)?
>     That would give you 4byte rows (instead of 8byte rows),
>     right?
>
>     Jon
>
>     On 2/24/2012 4:14 AM, Bengt Rutisson wrote:
>     >
>     > Hi all,
>     >
>     > Just pinging this review request. Does anybody have some time to look
>     > at it? It is a fairly small and straight forward change...
>     >
>     > Thanks,
>     > Bengt
>     >
>     > -------- Original Message --------
>     > Subject:     Request for review (S): 7068625 Testing 8 bytes of card
>     > table entries at a time speeds up card-scanning
>     > Date:     Tue, 21 Feb 2012 12:03:50 +0400
>     > From:     Alexey Ragozin <alexey.ragozin at gmail.com
>     <mailto:alexey.ragozin at gmail.com>>
>     > To: hotspot-gc-dev at openjdk.java.net
>     <mailto:hotspot-gc-dev at openjdk.java.net>
>     > CC:     Bengt Rutisson <bengt.rutisson at oracle.com
>     <mailto:bengt.rutisson at oracle.com>>
>     >
>     >
>     >
>     > Hi,
>     >
>     > I would like few volunteers to review changes for
>     > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068625
>     > WebRev: http://cr.openjdk.java.net/~brutisso/7068625/webrev.00/
>     <http://cr.openjdk.java.net/%7Ebrutisso/7068625/webrev.00/>
>     > <http://cr.openjdk.java.net/%7Ebrutisso/7068625/webrev.00/>
>     >
>     > Change summary
>     > For large heaps (I was focusing on 8GiB and above) it is common to
>     > have long continuous ranges of clean cards.
>     > Patch is introducing a short path for skipping ranges of clean cards
>     > using word aligned memory access instead of byte aligned.
>     >
>     > Patch affects serial and CMS collectors. For CMS collector stride
>     size
>     > should be increase to see any performance gains (I was using
>     > -XX:+UnlockDiagnosticVMOptions
>     > -XX:ParGCCardsPerStrideChunk=4096)
>     >
>     > For testing I was mainly using synthetic benchmark randomly modifying
>     > hash tables in heap, thus uniformly touching cards across heaps.
>     > Average duration of young GC pause were used as KPI.
>     > More details about testing can be found at
>     > http://blog.ragozin.info/2011/07/openjdk-patch-cutting-down-gc-pause.html
>     > Though article is referring jdk6, my resent tests with trunk jdk7
>     show
>     > no difference.
>     > I was also tested patch with real application (Oracle Coherence
>     > storage node).
>     > With 16GiB of heap and CMS/ParNew GC, enabling patch have
>     shortened GC
>     > pauses roughly in 2 times.
>     >
>     > Source code of benchmark used in test are available at
>     > https://gridkit.googlecode.com/svn/branches/aragozin-sandbox/young-gc-bench
>     >
>     > Main class YoungGCPauseBenchmark
>     >
>     > Regards,
>     > Alexey
>     >
>     >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20120227/f8e3554a/attachment-0001.html 


More information about the hotspot-gc-dev mailing list