Number of Parallel GC Threads
Thomas.Viessmann at Sun.COM
Fri Jan 23 07:49:32 UTC 2009
I totally agree in what you're saying. With the success of the
UltraSparc T1 and T2 processor families, this is becoming more
and more an issue. I'm in the customer service group and
an increasing number of service requests are due to mis-
or non-configuration of the parallel GC threads. Let's see what
the development team thinks about this. Many thanks.
Nicolas Michael wrote:
> 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.
mit freundlichen Gruessen / with kind regards
Global Sales and Services - Software Support Engineering
Sun Microsystems GmbH Phone: +49 (0)89 46008 2365 / x62365
Sonnenallee 1 Mobile: +49 (0)174 300 5467
D-85551 Kirchheim-Heimstetten Pager: Thomas.Viessmann at sun.itechtool.com
Germany/Deutschland mailto: Thomas.Viessmann at sun.com
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
More information about the hotspot-gc-dev