GC Parameters for low-latency (Ralf Helbing)

[Srinivas Ramakrishna]

Clearly the more dirty cards there are, the greater the time to scan them.
There are certain workloads
where you first build a bunch of data and then do your computation which
then mutates this long-lived
data. It is applications of that nature (typically found for example in
analytics) where the size of the
old generation matters for your scavenges. In typical cases, however, the
mutation of older objects
is very sparse, and in such cases you'd expect the scavenge costs to grow
much more slowly wrt
old gen size (definitely very siub-linear), whereas the dominant cost in
those cases would be
the size of the medium-lived data which you have to copy during a scavenge
(that is, to the
volume of the surviving data).

By the way, we do need to process your patch contribution (thanks!) to get
card-scanning to be more
speedy than it is today. That should hopefully help wrt the speeding up
card-scans from where
they are today (at least with CMS/ParNew where the promoted objects tend to
be more
scattered, this increasing card scanning costs when compared with most of
our other
old generation types).

-- ramki

On Wed, Nov 16, 2011 at 11:24 AM, Alexey Ragozin
<alexey.ragozin at gmail.com>wrote:

> Hi Ralf,
>
>>
>> we try to achieve low latencies despite using a huge heap (10G) and many
>> logical cores (64).
>> VM is 1.7u1. Ideally, we would let GC ergonomics decide what is best,
>> giving only a low pause time goal (50ms).
>>
>> -Xss2m
>> -Xmx10000M
>> -XX:PermSize=256m
>> -XX:+UseAdaptiveGCBoundary
>> -XX:+UseAdaptiveSizePolicy
>> -XX:+UseConcMarkSweepGC
>> -XX:MaxGCPauseMillis=100
>> -XX:ParallelGCThreads=12
>>
>> -XX:+BindGCTaskThreadsToCPUs
>> -XX:+UseGCTaskAffinity
>>
>> -XX:+UseCompressedOops
>> -XX:+DoEscapeAnalysis
>>
>> Whenever we use adaptive sizes, the VM will crash in GenCollect*, as
>> soon as some serious allocations start. I already filed a bug for this
>> (7112413).
>>
>> Assuming a small newsize helps maintaining a low pause time goal, I can
>> set the newsize, too. Say I set it to 100MB, it will increase later
>> anyway, again yielding frequent pause times in over 1s by the time the
>> newsize is around 1G.
>>
>> What am I doing wrong here?
>>
>
> Your assumption about correlation of new size and  pause time may be very
> wrong. My experiments (but on x86 architecture,not spark) has shown that
> young collection pause time on large heap mostly dominated by time required
> to scan dirty card table, thus proportional to old space size.You may find
> detailed math here
> http://aragozin.blogspot.com/2011/06/understanding-gc-pauses-in-jvm-hotspots.htmland some expiremental proof here
> http://aragozin.blogspot.com/2011/07/openjdk-patch-cutting-down-gc-pause.html
>
> As for recipe for low pause GC, I have outlined may here
> http://aragozin.blogspot.com/2011/07/gc-check-list-for-data-grid-nodes.html
> .
> But I have to say that again,all my expirience is relevant for x86, I will
> not be surprised too much if things work differently on sparc.
>
> PS
> sorry for posting so much links, but they are really helpful to catch up
> on topic of low pause GC tuning
>
> Regards,
> Alexey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111116/a0bd82dd/attachment.htm>