option combinations

[Victor Cheung]

Thanks, Ramki.  That makes sense.

Somebody should make a "-XX:+BestGCInTheWorldAndTheOnlyOptionYouWillEverNeedOption" option!  :)

victor


________________________________________
From: Y Srinivas Ramakrishna [Y.S.Ramakrishna at Sun.COM]
Sent: Sunday, December 14, 2008 1:54 PM
To: Victor Cheung
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: RE: RE: option combinations

The heap size and shape (sizes of individual spaces therein)
is probably the most important factor affecting the performance
of GC. The hope (and recent goal) has been that the rest of the
factors are there for getting the last ounce of performance
(or for working around specific anomalies) but should not be
used casually.

There are some useful pointers, including Jon's very
useful blog for deeper insights, starting from here:-

http://java.sun.com/javase/technologies/hotspot/gc/index.jsp

The points you made in this thread about options are all very
well-taken and we have been aware of some of these shortcomings
for a while now. I would encourage the community to file bugs for these
problems and also provide fixes when and where possible. That is
how we will improve usability and make the JVM more user-friendly.

-- ramki

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


> Thanks, Ramki.
>
> 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.
>
> victor
>
>
> ________________________________________
> 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
>     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