Question on ParallelGCThreads
Jon.Masamitsu at Sun.COM
Tue Sep 22 20:56:12 UTC 2009
On 09/22/09 12:46, Sujit.Das at cognizant.com wrote:
> Hi All,
> We use CMS collector for old generation collection (option
> -XX:+UseConcMarkSweepGC) and parallel copying collector for young
> generation (option -XX:+ UseParNewGC). We use ParallelGCThreads command
> line option (-XX:ParallelGCThreads=<desired number>) to control number
> of garbage collector threads.
> My question is:
> 1. Is ParallelGCThreads option applicable for only minor GC or is it
> applicable for old generation GC also?
Parts of the old generation collection that stop-the-world
and do work with multiple GC threads also use
ParallelGCThreads. This would be the initial-mark and
remark phases assuming you're using a recent release
(parallel initial-mark and parallel remark were not in the
first release of CMS).
Additionally, the concurrent marking that uses multiple GC
threads (introduced in jdk6) may be affected by ParallelGCThreads.
The number of GC threads used in the concurrent marking is
a fraction of ParallelGCThreads.
> 2. Since CMS collector is a non-compacting collector and if application
> faces memory fragmentation issue then reducing # of ParallelGCThreads is
> an option to reduce fragmentation. Please confirm the understanding.
> This is based on my reading that each garbage collection thread reserves
> a part of the old generation for promotions and the division of the
> available space into these "promotion buffers" can cause a fragmentation
> effect. Reducing the number of garbage collector threads will reduce
> this fragmentation effect as will increasing the size of the old
Yes, the promotion-local-allocation-buffers (PLAB's) can fragment
the old generation although that is not the most common cause.
There might have been an investigation of this type of fragmentation
recently. I'll ask around.
Increasing the size of the old gen ameliorates the affects of
fragmentation by giving objects more time to die and allows
CMS more time to coalesce dead space into larger blocks.
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.
> Any unauthorized review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on
> this e-mail is strictly prohibited and may be unlawful.
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev