Number of Parallel GC Threads

[Tony Printezis]

Nick,

First, a correction. For very large machines, we don't set the number of 
GC threads to be the same as the CPUs (there are diminishing returns if 
we do that). Currently, you get 1 parallel GC thread per CPU for up to 8 
CPUs, and 5/8 after that (so for 16 CPUs you get: 8 + 5/8 x 8 = 13 GC 
threads).

Now, regarding what we pick for the defaults: whatever we do, someone is 
going to be happy, and someone will not be. I've always seen the 
defaults as trying to do a not-so-embarrassing job for naive users. If 
someone is running several JVMs per box, then I assume that they know 
what they are doing, so playing around with the # of parallel GC threads 
should be straightforward to them! :-) And, incidentally, folks who do 
run more than one JVM per large box typically use processor sets or 
zones to partition the machines; in that case, our algorithm should do 
the right thing.

Tony

Nicolas Michael wrote:
> Hi,
>
> on server-class machines, you are using the ParallelGC collector as the default
> collector. This collector is per default using as many parallel gc threads as
> there are cpus in the system. As far as I remember, you are doing this because
> you are assuming that people usually just run one JVM on their server, so you're
> optimizing for that case -- and telling people to explicitly decrease their
> number of gc threads when running multiple JVM's. (As some of you know, we are
> doing just that for our "most important" JVM instances we're running.)
>
> However, we also have some little Java-based agents running on our systems which
> just use the defaults. On our T5240's and T5440's they end up having 128 resp.
> 256 parallel gc threads! I'm wondering whether this is really a "reasonable"
> default behavior?! Would someone really run just one JVM on such a large system?
> Does it make sense to have 256 parallel gc threads as a *default* on such
> servers? I was thinking that it may be better to limit the maximum number of
> parallel gc threads that are created per default to a more "conservative" number
> (whatever this number would be... 16? 32? ...?).
>
> Well, this is just a thought. I could imagine that there are lots of Java-based
> tools around (management GUIs, ...) that people run on their servers. And many
> of those tools usually don't set any JVM parameters except probably the max heap
> size. If I was starting such a tool as an operator, I wouldn't want it to
> interrupt my workload by doing garbage collection with 256 threads in parallel.
>
> Another idea: The demand for many gc threads also depends a little on the heap
> size. An application with a default 64m heap will most likely not benefit much
> from 256 gc threads, while an application with 4g of heap might. So the heap
> size could be another indication of how many parallel gc threads would make
> sense as a default.
>
> I'd be interested to hear your opinion on that.
>
> Thanks,
> Nick.
>
>   

-- 
----------------------------------------------------------------------
| Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
|                                   | MS BUR02-311                   |
| e-mail: tony.printezis at sun.com    | 35 Network Drive               |
| office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
----------------------------------------------------------------------
e-mail client: Thunderbird (Solaris)