Avoiding 1 long CMS with a big heap

Matt Khan matt.khan at db.com
Wed Apr 14 04:28:03 PDT 2010


I have been experimenting with larger heap sizes to see if I can reduce 
the frequency of my pauses, the switches I have used are;


This works quite well in that our average pause time is ~4ms every 30s or 
so (albeit in the range 5-60s but most commonly about every 30s).

There is one wrinkle and that is an initial, v long CMS pause. It happens 
about ~40mins after start

2010-04-13T23:05:29.072+0000: 3342.854: [GC [1 CMS-initial-mark: 
12018K(196608K)] 7811496K(16564608K), 4.2147116 secs] [Times: user=4.15 
sys=0.06, real=4.22 secs] 
Total time for which application threads were stopped: 4.2243800 seconds
2010-04-13T23:05:33.288+0000: 3347.070: [CMS-concurrent-mark-start]
Application time: 0.0021391 seconds
Total time for which application threads were stopped: 0.0046091 seconds
2010-04-13T23:05:33.343+0000: 3347.125: [CMS-concurrent-mark: 0.048/0.056 
secs] [Times: user=0.35 sys=0.15, real=0.06 secs] 
2010-04-13T23:05:33.344+0000: 3347.126: [CMS-concurrent-preclean-start]
2010-04-13T23:05:33.347+0000: 3347.128: [CMS-concurrent-preclean: 
0.003/0.003 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] 
2010-04-13T23:05:33.347+0000: 3347.129: 
 CMS: abort preclean due to time 2010-04-13T23:05:38.456+0000: 3352.238: 
[CMS-concurrent-abortable-preclean: 0.573/5.109 secs] [Times: user=0.94 
sys=0.24, real=5.11 secs] 
Application time: 4.1574245 seconds
2010-04-13T23:05:38.461+0000: 3352.243: [GC[YG occupancy: 7824966 K 
(16368000 K)]3352.243: [Rescan (parallel) , 4.2295340 secs]3356.473: [weak 
refs processing, 0.0000422 secs] [1 CMS-remark: 12018K(196608K)] 
7836984K(16564608K), 4.2298963 secs] [Times: user=36.56 sys=1.65, 
real=4.23 secs] 
Total time for which application threads were stopped: 4.2351364 seconds
2010-04-13T23:05:42.692+0000: 3356.473: [CMS-concurrent-sweep-start]
Application time: 0.0003415 seconds

What I would like to understand is why there is such a long pause when the 
tenured is nowhere near full (~12m of 192m occupied)? and hence whether 
this can be avoided?


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

More information about the hotspot-gc-dev mailing list