Number of Parallel GC Threads

[Nicolas Michael]

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.