CMS & DefaultMaxTenuringThreshold/SurvivorRatio

[Y. Srinivas Ramakrishna]

Hi Shaun --

Jon Masamitsu wrote:
> 
> Only the througput collector has GC ergonomics implemented.  That's
> the feature that would vary eden vs survivor sizes and the tenuring
> threshold.

Just to clarify, that should read "_max_ tenuring threshold" above.
The tenuring threshold itself is indeed adaptively varied from
one scavenge to the next (based on survivor space size and object
survival demographics, using Ungar's adaptive tenuring algorithm)
by CMS and the serial collector. A different scheme determine the
tenuring threshold used per scavenge by Parallel GC.
Ask again if you want to know the difference between per-scavenge
tenuring threshold (which is adaptively varied) and
_max_ tenuring threshold (which is spec'd on the command-line).

But yes the rest of the things, heap size, shape, and _max_ tenuring threshold
would need to be manually tuned for optimal performance of CMS. Read the GC
tuning guide for how you might tune the survivor space size and
max tenuring threshold for your application using PrintTenuringDistribution data.

> 
>> Also still curious if XX:ParallelGCThreads should be set to 16
>> (#cpus)-- if my desire is to minimize time spent
>> in STW GC time?
> 
> 
> Yes 16 on average will minimize the STW GC pauses but occasionally
> (pretty rare actually), there can be some interaction between the GC using
> all the hardware threads and the OS needing one.

I have occasionally found that unless you have really large Eden sizes, fewer
GC threads than CPU's often give you the best results. But yes you are in the
right ball-park by growing the number of GC threads as your cpu count, cache size per cpu
and heap size increase. With a 4GB young gen as you have, i'd try 8 through 16
gc threads to see what works best.

-- ramki
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use