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 18:41:17 UTC 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120227/f8e3554a/attachment.htm>
More information about the hotspot-gc-dev
mailing list