Incremental CMS: long "[GC [1 CMS-initial-mark:"

[Andrei Pozolotin]

    Ramki, hi

    Thank you for quick response;

    from reading JDK 6 source I deluded myself that the problem you
    describe:

    "... occurs sometime between two scavenges ..."

    would get fixed by these options:

    wrapper.java.additional.175=-XX:+CMSParallelRemarkEnabled
    wrapper.java.additional.176=-XX:+CMSScavengeBeforeRemark
    wrapper.java.additional.177=-XX:CMSIncrementalOffset=10
    wrapper.java.additional.178=-XX:CMSScheduleRemarkEdenPenetration=5

    please confirm I was wrong?

    Cheers,

    Andrei



-------- Original Message  --------
Subject: Re: Incremental CMS: long  "[GC [1 CMS-initial-mark:"
From: Y. Srinivas Ramakrishna <Y.S.Ramakrishna at Sun.COM>
To: Andrei Pozolotin <andrei.pozolotin at gmail.com>
Cc: hotspot-gc-use at openjdk.java.net
Date: Wed 17 Feb 2010 04:42:34 PM CST
> On 02/17/10 14:28, Andrei Pozolotin wrote:
>>       *Jon, *hello;
>>
>>     I need to convert CMS into incremental CMS to reduce latency,
>>     eliminate occasional "concurrent mode failure" - related pauses;
>>
>>     and I am running into the following problem:
>>
>>     1) in "normal CMS" - [GC [1 CMS-initial-mark: takes 50 milliseconds
>>
>>     2) in "incremental CMS" - [GC [1 CMS-initial-mark:  takes 800
>>     milliseconds
>
> This is to be expected and is a consequence of how and when
> the initial mark is done in "normal" vs "incremental".
> In the former, the initial mark almost immediately follows
> after a scavenge pause and Eden is empty. In the latter case
> it normally occurs sometime between two scavenges by which time
> Eden has objects in it. For various reasons, the young gen
> is scanned as a source of initial roots to mark from,
> and for various reasons it is currently the case that this
> work is done single-threaded.
>
> As you will find, the magnitude of this difference typically
> depends (among other factors) on the size of Eden you specify
> (being directly proportional to it) and the duty cycle you
> specify (being inversely proportional to it).
>
> There are ways to fix this in the JVM, but no real workaround that
> i can think of at the command-line level.
>
> If this is important, please file a bug on this via your
> support contacts.
>
> thanks!
> -- ramki
>
>>
>>     both above results are under same no-load conditions,
>>     with non-reducible statuc heap object set of 430 MB
>>     composed of some 350K complex objects;
>>
>>     I can not understand why and how to fix it;
>>     I tried a lot of Incremental CMS - related option combinations,
>>     still dead end.
>>
>>     GC settings, log attached;
>>
>>     Thank you for your help,
>>
>>     Andrei
>>
>>     ++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>     # use server-style JIT compiler
>>     wrapper.java.additional.100=-server
>>
>>     # do GC logging
>>     wrapper.java.additional.110=-verbose:gc
>>     wrapper.java.additional.111=-Xloggc:./logs/gc.log
>>     wrapper.java.additional.112=-XX:+PrintGCDetails
>>     wrapper.java.additional.113=-XX:+PrintGCTimeStamps
>>
>>     # Heap Total = PermGen + NewGen + OldGen;
>>     wrapper.java.additional.120=-Xms3700m
>>     wrapper.java.additional.121=-Xmx3700m
>>
>>     # PermGen;
>>     wrapper.java.additional.130=-XX:PermSize=50m
>>     wrapper.java.additional.131=-XX:MaxPermSize=50m
>>
>>     # NewGen; Parallel collector;
>>     wrapper.java.additional.140=-XX:NewSize=1200m
>>     wrapper.java.additional.141=-XX:MaxNewSize=1200m
>>     wrapper.java.additional.142=-XX:-UseAdaptiveSizePolicy
>>     wrapper.java.additional.143=-XX:SurvivorRatio=1
>>     wrapper.java.additional.144=-XX:TargetSurvivorRatio=90
>>     wrapper.java.additional.145=-XX:MaxTenuringThreshold=3
>>     wrapper.java.additional.146=-XX:+UseParNewGC
>>     wrapper.java.additional.147=-XX:-UseParallelGC
>>     wrapper.java.additional.148=-XX:ParallelGCThreads=4
>>
>>     # OldGen; Incremental CMS collector;
>>     wrapper.java.additional.170=-XX:-UseParallelOldGC
>>     wrapper.java.additional.171=-XX:+UseConcMarkSweepGC
>>     wrapper.java.additional.172=-XX:+CMSIncrementalMode
>>     wrapper.java.additional.173=-XX:-CMSIncrementalPacing
>>     wrapper.java.additional.174=-XX:CMSIncrementalDutyCycle=1
>>     wrapper.java.additional.175=-XX:+CMSParallelRemarkEnabled
>>     wrapper.java.additional.176=-XX:+CMSScavengeBeforeRemark
>>     wrapper.java.additional.177=-XX:CMSIncrementalOffset=10
>>     wrapper.java.additional.178=-XX:CMSScheduleRemarkEdenPenetration=5
>>     wrapper.java.additional.179=-XX:CMSWaitDuration=60000
>>     wrapper.java.additional.181=-XX:ParallelCMSThreads=1
>>     wrapper.java.additional.182=-XX:PrintCMSStatistics=0
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20100217/2a6e3c0f/attachment.html