Parallel GC thread priority

Vitaly Davidovich vitalyd at
Fri Sep 7 15:35:02 UTC 2012

You can have other threads from different processes in the system competing

However, such a large wall time vs CPU time can also be caused by heavy
swapping on a slow disk.  The heap there doesn't look all that big though

Sent from my phone
On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at> wrote:

>  The Parallel collector is a stop-the-world collector.  The Java threads
> are suspended until the GC finishes.  I think your survivor spaces maybe
> mis-configured, and that's why you're seeing such large GC times.
> On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>  Hi,
> I can see that Parallel GC works on threads with NormPriority, while CMS
> and G1 threads run with NearMaxPriority. This probably not an issue if java
> application works alone, but some time ago I observed GC log like this (it
> was Jenkins CI on Windows):
> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41,
> real=30.26 secs]
> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time
> was 30.26 sec! It seems to me that the system was busy that time and GC
> threads was starving.
> If we could raise priority of Parallel GC threads, other application would
> have less impact on GC duration.
> What do you think?
> Thanks,
> Dmytro
> --
> Azeem Jiva
> @javawithjiva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list