Avoiding 1 long CMS with a big heap

Matt Khan matt.khan at db.com
Wed Apr 14 14:15:27 PDT 2010

>> The first initial-mark had a full GC just before it (right?) so the 
young gen was likely empty.
that's right

>> If you run your test case longer and see mostly longer initial-marks, 
that would suggest that my guess is right.
the young gen is definitely not empty when the 2nd initial mark was 
triggered. There has been no further CMS activity since then so 
approaching 24hrs now, occupation of tenured has hovered ~30MB all day. 

I still don't understand *why* the 2nd initial mark happened. I thought 
CMS was only triggered once the occupation passed the threshold (IIRC this 
is 50% by default), since occupation was actually more like 10% or so then 
why did it even feel the need to do anything at all?

>> If you add -XX:+CMSScavengeBeforeRemark it will schedule a ParNew 
collection before the remark.
slightly naive Q.... why isn't this default behaviour? is it because a 
"normal" heap has a bigger tenured than eden hence the cost isn't skewed 
in the way I have it configured?

>> Just drop the incremental option and you would be fine in this case.
I'll give that a try and report back.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100414/1b7657a0/attachment-0001.html 
-------------- next part --------------
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net

More information about the hotspot-gc-dev mailing list