option combinations

[Y Srinivas Ramakrishna]

My email below might have been slightly confusing the way it was
written. Explicit command-line settings of course always
override any default choices the JVM might otherwise have made.

-- ramki


----- Original Message -----
From: Y Srinivas Ramakrishna <Y.S.Ramakrishna at Sun.COM>
Date: Sunday, December 14, 2008 9:35 am
Subject: Re: RE: option combinations
To: Victor Cheung <VictorC at ganz.com>
Cc: "hotspot-gc-use at openjdk.java.net" <hotspot-gc-use at openjdk.java.net>


> 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
>     calue accordingly.
> 
> (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
>     really wanted.
> 
> (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
> running concurrently.
> 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.
> 
> -- ramki
> 
> 
> > 
> > victor
> > 
> > ________________________________________
> > 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
> > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use