VictorC at ganz.com
Sun Dec 14 11:23:31 PST 2008
I know what you mean. But for me, ignorance is bliss. I always shoot myself in the foot it seems!
From: Michael Finocchiaro [michael.finocchiaro at gmail.com]
Sent: Sunday, December 14, 2008 2:18 PM
To: Y Srinivas Ramakrishna
Cc: Victor Cheung; hotspot-gc-use at openjdk.java.net
Subject: Re: option combinations
Just be thankful that some of these can be tinkered with. I am not
obliged to use a JVM with almost no tweak room: IBM's Java for
Sent from Fino's iPhone 3G
On 14 déc. 08, at 19:54, Y Srinivas Ramakrishna
<Y.S.Ramakrishna at Sun.COM> wrote:
> 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:-
> 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
> 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.
>> 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
>>> 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
>> 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
>> 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
>>> for each JVM (among others) would be: -XX:+UseParNewGC
>>> -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 -
>> ParallelCMSThreads=4 is too many. The JVM chooses
>> ParallelCMSThreads to
>> be roughly 1 for every 4 ParallelGCThreads. Recall that
>> is the number used only for the _concurrent_ phases of the
>> where you will (1) not need so many collector threads (2) will
>> not like the resulting interference with the mutator threads which
>> running concurrently.
>> So if you had not set ParallelCMSThreads explicitly above, but just
>> ParallelGCThreads you would have gotten by default
>> (or essentially the equivalent of a single-threaded concurrent
>> If you are dissatisfied with the speed of the concurrent phases of
>> GC you might want to adjust ParallelCMSThreads upward to say 2, but
>> any larger value is likely to be too large.
>>> Is this correct?
>>> The JDK version we are using is 6u5... does this version support
>> Yes it does.
>> -- ramki
>>> 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
>>> 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
> 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