ParallelGCThreads

Y Srinivas Ramakrishna Y.S.Ramakrishna at Sun.COM
Tue Apr 1 14:04:12 PDT 2008


Hi Paul --

> I recently discovered we were overriding this value. I think there is
> some history behind this I can no longer. Regardless, I am looking to
> either pull this out or adjust it based on our 16 way servers. What I'd
> like to know is  - what is the default value? I recall it being a

For +UseParallelGC the default value is the number of cores on the platform
(or pset that the JVM instance is bound to). This will change in the near future,
watch for an update on this alias as the changes are pushed out in open jdk 7 soon.

For +UseConcMarkSweepGC/+UseParNewGC  the default is computed as:

     (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)

(where ncpus is the # cores on the platform or in the pset of the JVM set is
bound to a pset).

> formula based on the number of processors. Just to make this post more
> interesting can you tell me why I would not want to make this equal to
> or even greater than the number of processors? My process is not the
> sole occupant on the machine so there no expectation of being able to
> use 100% of the machine during a cycle.
> 

Having many more net GC worker threads than cores will often increase
GC termination times because workers with work to do will not get time on
a CPU. This can appear as either longer (or more erratic) GC pauses,
that might translate into erratic application-level response times.
There is an RFE to try and correct this by modifying the load-balancing
(work stealing) and termination algorithms used by GC.

I'll dig up and post the related CR's.
-- ramki



More information about the hotspot-gc-dev mailing list