Parallel GC thread priority

[Vitaly Davidovich]

Whether it helps or not would depend on what priority the other threads are
running at.  If the server had several jvms running at the same time and
they all start a par new collection at about the same time, then yeah it
won't help if priority is boosted - at that point, the machine is simply
oversubscribed.

In Dmytro's case, the wall time is so out of whack with CPU time that I
wonder if it wasn't swapping that mostly contributed to this.  For such a
relatively small heap, I can't imagine how much other stuff would have to
run to inflate the time so much.

Dmytro, what hardware spec was this on, out of curiosity?

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

>  I had not thought about other processes, which is a possibility.
> Although raising the priority of the GC threads won't help which I believe
> what Dmytro was suggestion.
>
>
> On 09/07/2012 10:35 AM, Vitaly Davidovich wrote:
>
> You can have other threads from different processes in the system
> competing though.
>
> 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 oracle.com> 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
>>
>>
> --
> Azeem Jiva
> @javawithjiva
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/9355549a/attachment.htm>