CMS initial mark pauses

Adam Hawthorne adamh at
Mon Oct 18 20:49:30 UTC 2010

On Thu, Oct 14, 2010 at 19:00, Y. S. Ramakrishna <y.s.ramakrishna at
> wrote:

> Hi Adam --
> ...
>> I have CMSInitiatingOccupancyFraction=50 because I was concerned about
>> some finalization issues in our application, and I thought I remembered
>> reference processing wasn't done in young GC's.  After enabling
>> PrintReferenceGC, the logs imply  ParNewGC also clears references - is that
>> true?  If so, it may not be necessary for us to include that option anyway.
> Yes, scavenges do process unreachable Reference objects found in the young
> gen.
> However, once these get into the old gen, you are right that you will need
> a
> CMS cycle to identify them as unreachable and to process them
> appropriately.
>>    Here's an excerpt from the "workaround" section of that bug
>>    ...
>  The customer's application appears to fit neatly in a 2.4G heap, and we
>> have -Xmx4g, so I believe we might be able to apply (2) here.  Is (1) above
>> required along with (2), or do these workarounds address the problem
>> independently?  I ask because (a) this customer is already concerned about
>> pause times, so I don't have a lot of room to increase remark and scavenge
>> times, and (b) I'm concerned about eliminating survivor spaces since we've
>> dealt with significant heap fragmentation in the past.
> Precisely. The two are actually additive, but either by itself may not
> be sufficient, and as you pointed out (1) may not even be always feasible.
> ...
> -- ramki

Just a followup - I removed the CMSInitiatingOccupancyFraction, and I tried
to fulfill the spirit of the workaround by setting the SurvivorRatio to
significantly limit the survivor space size.  The customer mistyped one of
the logging parameters, so I wasn't able to get the logs from that day, but
the report was that performance suffered significantly

I looked back at the logs and discovered that every initial-mark that
followed immediately after or even modestly soon after a young gc was well
within the pause time requirement.  Only those which were more than halfway
to the next young generation were long, just as Ramki predicted.

So all I did was remove the CMSInitiatingOccupancyFraction and set the heap
size to 4g, and the system was reported to be working well today.

I ran some tests with G1 today, but I'll post a separate thread about that.

Thanks for the help.


Adam Hawthorne
Software Engineer
BASIS International Ltd.
+1.505.345.5232 Phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
hotspot-gc-use mailing list
hotspot-gc-use at

More information about the hotspot-gc-dev mailing list