option combinations

[Michael Finocchiaro]

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  
WebSphere :(

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:-
>
> 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
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use