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

[Alexey Ragozin]

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>
> 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
> Message-ID: <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>
> > To:     hotspot-gc-dev at openjdk.java.net
> > CC:     Bengt Rutisson <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/>
> >
> > 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120227/4a1f756d/attachment.htm>