Number of Parallel GC Threads

[Jon Masamitsu]

Nick,

The simpliest solution for your problem is to run the
small applications with -client.

This is a basic "one size does not fit all" problem.  For
many years we ran the JVM with -client as the default
and we got plenty of  complaints about poor
performance.  Some of it went along the lines of
"You're running on a huge system, why don't you
use it".

In the latest jdk 6 updates the default number of threads
is less than the number of CPU's.   For  a T5240 (128 hardware
threads) I think it will be about 40 GC threads.
Of course that is still too many for the small applications.

By the way, on a server class machine the default
heap size depends on the amount of physical memory
(use 1/4 of the physical memory as the default maximum
heap size).  So we cannot use the maximum heap size
as a way to decide how many GC threads to use.   A
customer would have to add a different maximum
heap size.  If they are willing to do that, they should
just add -client when appropriate.

When the JVM initializes, it knows nothing about the
application so cannot tell if it is "big" or "small".    We
don't maintain a database of applications in order to
tell what are good numbers to use for each application
and there is no project in the works to do that.

We've wanted to add to the JVM the ability to monitor
the resources of the system that it is running on and
to modify its behavior (i.e., if there are lots of processes
running, reduce the maximum size of the heap and
number of GC threads) but we have no one to work on
it.

Jon


Nicolas Michael wrote On 01/22/09 23:26,:

>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.
>
>  
>