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

[Y. Srinivas Ramakrishna]

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