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

Wed Feb 17 15:42:14 PST 2010

    Ramki, hello again;

    1) "unfortunately" - got it; thank you;

    2) thanks for G1 idea; will try now;

    3) it does not seem gchisto / visualvm can see G1 at all;
    can you please recommend a tool that can help with G1 tuning?

    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 05:31:23 PM CST
> On 02/17/10 14:57, Andrei Pozolotin wrote:
>>     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?
>
> Yes, unfortunately, those are in some sense orthogonal to
> the way CMS "incrementalizes" its working, here (somewhat
> relatedly see [1])
>
> For example, CMSScavengeBeforeRemark does indeed schedule a scavenge
> before a remark pause, but not (unfortunately) before an initial
> mark pause. Similarly the CMSScheduleRemarkEdenPenetration
> controls the scheduling of remark pauses, not the initial
> mark pauses.
>
> As for CMSIncrementalOffset, it is just a constant positive delta
> applied to the ideal starting point for a given duty cycle.
> So, in fact, any positive value will take you further away
> from the objective you are trying to achieve here of reducing
> the occupancy of Eden when initial mark hits.
>
> Try G1, that may save you filing an RFE on (i)CMS for this.
>
> Honestly though, there is an existing blanket RFE on this:
>   6412968 CMS: Long initial mark pauses
> but it has not risen to the top of our list of things to fix.
>
> If this is important, please contact your Java support....
>
> -- ramki
>
> [1] 6518192 iCMS: smoother, duration-bounded incrementality
>
>
>>     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/7646c6fc/attachment-0001.html