VictorC at ganz.com
Sun Dec 14 10:09:31 PST 2008
That's a good point, i have to confirm with the admin if they have bound the JVMs to any processor sets.
Wow. Another "OMG!" moment for me. Thanks for pointing that out about the ParallelCMSThreads=4 is too high.
It definitely seems like there are 2 classes of options. The "general/basic" class of options like Xms, Xmx. And then the "hardcore" options like ParallelCMSThreads, and many others. Perhaps, there should be warnings beside every "hardcore" option because they obviously require intimate knowledge and/or a very good understanding of the inner workings of garbage collecting.
From: Y Srinivas Ramakrishna [Y.S.Ramakrishna at Sun.COM]
Sent: Sunday, December 14, 2008 12:33 PM
To: Victor Cheung
Cc: Michael Finocchiaro; hotspot-gc-use at openjdk.java.net
Subject: Re: RE: option combinations
Hi Victor --
> does this mean i should be setting ParallelGCThreads and
> ParallelCMSThreads if i am using ParNew and CMS on a multi-core system
> with more than one JVM running?
Here's the situation:-
(1) if you have yr JVM's bound to processor sets, then the JVM will
choose a default value for ParallelGCThreads that it considers
reasonable for that pset. It also chooses a suitable ParallelCMSThreads
(2) If you do not have the JVMs bound to processor sets, then the JVM
might choose default values for these that might be more than you
(3) If you only set ParallelGCThreads explicitly, and not ParallelCMSThreads,
then the JVM will choose a default value of the latter based on
a specific fraction of the former.
> So for example, if i had 2 JVMs running on a 8 CPU machine, my options
> for each JVM (among others) would be: -XX:+UseParNewGC
> -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 -XX:ParallelCMSThreads=4
ParallelCMSThreads=4 is too many. The JVM chooses ParallelCMSThreads to
be roughly 1 for every 4 ParallelGCThreads. Recall that ParallelCMSThreads
is the number used only for the _concurrent_ phases of the collection
where you will (1) not need so many collector threads (2) will probably
not like the resulting interference with the mutator threads which are
So if you had not set ParallelCMSThreads explicitly above, but just
ParallelGCThreads you would have gotten by default ParallelCMSThreads=1
(or essentially the equivalent of a single-threaded concurrent phase).
If you are dissatisfied with the speed of the concurrent phases of
GC you might want to adjust ParallelCMSThreads upward to say 2, but almost
any larger value is likely to be too large.
> Is this correct?
> The JDK version we are using is 6u5... does this version support ParallelCMSThreads?
Yes it does.
> From: Y Srinivas Ramakrishna [Y.S.Ramakrishna at Sun.COM]
> Sent: Sunday, December 14, 2008 3:17 AM
> To: Michael Finocchiaro
> Cc: hotspot-gc-use at openjdk.java.net; Victor Cheung
> Subject: Re: option combinations
> > I think that Java6 gave us control for the CMSThreads or am I mistaken?
> Right ParallelCMSThreads controls the number of threads
> used in the concurrent (marking) phase(s) in 6uXX.
> -- ramki
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev