hotspot-gc-dev Digest, Vol 56, Issue 25

[Alexey Ragozin]

Hi,

On my test system, benefit from patch on 4GiB heap on CMS + ParNew was
just about 5ms (64 bit JVM though).
On the other side on smaller heap - greater density of dirty card. It
is possible that testing 4 cards instead of 8 is better for smaller
heaps.

Anyway, I'm pretty happy with GC times for 32 bit heaps :)

Regards,
Alexey

> Date: Mon, 27 Feb 2012 10:41:17 -0800
> 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: <4F4BCE4D.4030902 at oracle.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
>>     >
>>     >