longer ParNew collection in JDK8?

[Jon Masamitsu]

Joy,

Try running with

-XX:+UnlockDiagnosticVMOptions
-XX:+BlockOffsetArrayUseUnallocatedBlock

It may not be safe to run that way (see
https://bugs.openjdk.java.net/browse/JDK-6948538 )

I haven't read through the bug trail to see if this
has been fixed in a later release.

Please let me know if this is the cause of the
slowdown.

Jon


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/20150224/9cf56705/attachment-0001.html>