What influences young generation pause times?

[Matt Khan]

Hi Tony

>> Basically, the more objects survive the collection and need to be 
copied, the higher the young GC times will be.
so when does a concurrent collector enter a STW pause? 

for example if I look at figure 6, p10 in the memory management white 
paper (http://java.sun.com/products/hotspot/whitepaper.html) then that 
makes it look like there is a single STW pause per young collection that 
is made shorter because there are n threads doing the work. Is that an 
accurate depiction of when it pauses or just a convenient visualisation?

My reason for asking is that my app doesn't exhibit this single pause per 
young collection, instead I see a succession of short pauses between GC 
logs (example below) & I'd like to understand what causes those pauses. 
This app is using CMS (params used below) but there is no CMS activity 
reported at this time because v little enters the tenured generation and 
hence there is no collection required.

Total time for which application threads were stopped: 0.0051359 seconds
Application time: 99.9576332 seconds
2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew
Desired survivor size 14450688 bytes, new threshold 1 (max 1)
- age   1:    3377144 bytes,    3377144 total
: 2986668K->4491K(2998976K), 0.0254753 secs] 3076724K->94963K(3130048K) 
icms_dc=0 , 0.0259072 secs] [Time
s: user=0.25 sys=0.01, real=0.03 secs] 
Total time for which application threads were stopped: 0.0330759 seconds
Application time: 190.7387185 seconds
Total time for which application threads were stopped: 0.0060798 seconds
Application time: 9.2698867 seconds
Total time for which application threads were stopped: 0.0051861 seconds
Application time: 290.7195886 seconds
Total time for which application threads were stopped: 0.0065455 seconds
Application time: 9.2792321 seconds
Total time for which application threads were stopped: 0.0051541 seconds
Application time: 290.7292153 seconds
Total time for which application threads were stopped: 0.0063071 seconds
Application time: 9.2696694 seconds
Total time for which application threads were stopped: 0.0052036 seconds
Application time: 290.7093779 seconds
Total time for which application threads were stopped: 0.0065365 seconds
Application time: 9.2793591 seconds
Total time for which application threads were stopped: 0.0051265 seconds
Application time: 290.7301471 seconds
Total time for which application threads were stopped: 0.0070431 seconds
Application time: 9.2694376 seconds
Total time for which application threads were stopped: 0.0051428 seconds
Application time: 119.4074368 seconds
Total time for which application threads were stopped: 0.0059739 seconds
Application time: 39.8647697 seconds
2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew
Desired survivor size 14450688 bytes, new threshold 1 (max 1)
- age   1:    2911824 bytes,    2911824 total

-Xms3072m 
-Xmx3072m 
-Xmn2944m 
-XX:+DisableExplicitGC 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCApplicationConcurrentTime
-XX:MaxTenuringThreshold=1 
-XX:SurvivorRatio=190 
-XX:TargetSurvivorRatio=90
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 

Cheers
Matt

Matt Khan
--------------------------------------------------
GFFX Auto Trading
Deutsche Bank, London



---

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use