longer ParNew collection in JDK8?

[Staffan Friberg]

Hi Joy,

I don't think it is worth while exploring this further.

The reason for me asking was that on a particular workload I saw that 
the increased work stealing before yielding caused longer young 
collections times. The updated value generally improves or doesn't 
affect the YC times, but have seen at least one case and wanted to make 
sure it was not more common than we believed when updating it.

Thanks for taking the time to verify.

//Staffan

On 02/06/2015 11:17 AM, Joy Xiong wrote:
> I tried the experimental flag:
> -XX:+UnlockExperimentalVMOptions -XX:WorkStealingYieldsBeforeSleep=1000
> but the ParNew pause time is very close to JDK8 without the change.
>
> Here is the comparison data of ParNew pause in millisecond:
> JDK6: 13
> JDK8: 36
> JDK8 (with WorkStealingYieldsBeforeSleep=1000): 38
>
> I notice there are 4 tunables related with WorkStealingXXX, I am not 
> clear what these tunables are. But is it worthwhile to try a 
> combination of these?
> /WorkStealingYieldsBeforeSleep/,
> /WorkStealingHardSpins /
> /WorkStealingSleepMillis /
> /WorkStealingSpinToYieldRatio /
>
> thanks,
> -Joy
>
>
> On Wednesday, February 4, 2015 2:45 PM, Joy Xiong <joyxiong at yahoo.com> 
> wrote:
>
>
> Hi Staffan,
>
> Thanks for the suggestion. I will try to find an experimental testbed 
> and give it a try. Also for you info, it seems to me the longer ParNew 
> pause is introduced in JDK7, as I saw similar increase when I used JDK7.
>
> thanks,
> -Joy
>
>
> On Wednesday, February 4, 2015 9:57 AM, Staffan Friberg 
> <staffan.friberg at oracle.com> wrote:
>
>
> Hi Joy,
>
> Could you try with the following extra option, it would change the 
> setting to be similar in JDK 7 as they are in JDK 6.
>
> -XX:+UnlockExperimentalVMOptions -XX:WorkStealingYieldsBeforeSleep=1000
>
> //Staffan
>
> On 02/02/2015 10:38 AM, Joy Xiong wrote:
>> Hi Jon,
>>
>> Yes, most objects in my application die young and very little 
>> promoted. As you can see from the attached figure (the occupied heap 
>> size from Sep 28 to Nov 11), CMS happened very rare. However, it 
>> seems two releases do not have much difference in promotion rate, as 
>> they have same number of CMS in the log.
>>
>> We have the same JVM parameters for both releases as below:
>>
>> CommandLine flags: -XX:+AlwaysPreTouch 
>> -XX:CMSInitiatingOccupancyFraction=70 -XX:ErrorFile=logs/hs_err.log 
>> -XX:InitialHeapSize=34271657984 -XX:+ManagementServer 
>> -XX:MaxHeapSize=34271657984 -XX:MaxNewSize=2147483648 
>> -XX:NewSize=2147483648 -XX:OldPLABSize=16 -XX:+PrintGC 
>> -XX:+PrintGCApplicationConcurrentTime 
>> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps 
>> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
>> -XX:+PrintTenuringDistribution -XX:SurvivorRatio=2 
>> -XX:+UnlockDiagnosticVMOptions -XX:+UseCompressedClassPointers 
>> -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
>>
>> thanks,
>> -Joy
>>
>>
>> On Monday, February 2, 2015 10:06 AM, Jon Masamitsu 
>> <jon.masamitsu at oracle.com> <mailto:jon.masamitsu at oracle.com> wrote:
>>
>>
>> Joy,
>>
>> Is your application such that most everything dies in the
>> young generation and very little is promoted?  If yes,
>> do you know if there is a difference in how much is
>> promoted between the two releases?
>>
>> Jon
>>
>> On 01/29/2015 10:27 AM, Joy Xiong wrote:
>>>
>>> Hi,
>>>
>>> We recently move our services from JDK6 to JDK8, but observe longer 
>>> ParNew GC pause in JDK8. For example, the pause time increase from 
>>> 27ms to 43ms in one service. The service has the JVM parameters as 
>>> below:
>>> -Xms32684m -Xmx32684m -XX:NewSize=2048m -XX:MaxNewSize=2048m 
>>> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 
>>> -XX:CMSInitiatingOccupancyFraction=70 -XX:SurvivorRatio=2 
>>> -XX:+AlwaysPreTouch -XX:+UseCompressedOops 
>>> -XX:+PrintTenuringDistribution -XX:+PrintGCDetails 
>>> -XX:+PrintGCDateStamps -Xloggc:logs/gc.log 
>>> -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime
>>>
>>> Is this longer ParNew pause expected? Any suggestions to mitigate 
>>> the longer pause?
>>>
>>> thanks,
>>> -Joy
>>>
>>>
>>> _______________________________________________
>>> hotspot-gc-use mailing list
>>> hotspot-gc-use at openjdk.java.net  <mailto:hotspot-gc-use at openjdk.java.net>
>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net <mailto:hotspot-gc-use at openjdk.java.net>
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>>
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net  <mailto:hotspot-gc-use at openjdk.java.net>
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20150206/e6d9d8f0/attachment-0001.html>