longer ParNew collection in JDK8?

[Joy Xiong]

I tried the experimental flag: -XX:+UnlockExperimentalVMOptions -XX:WorkStealingYieldsBeforeSleep=1000but the ParNew pause time is very close to JDK8 without the change.
Here is the comparison data of ParNew pause in millisecond:JDK6: 13JDK8: 36JDK8 (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> 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
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
 
  
   
 _______________________________________________
 hotspot-gc-use mailing list
 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
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/e3bf4daf/attachment-0001.html>