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

[Y. Srinivas Ramakrishna]

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
>>
>>
>