CMS initial mark pauses

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


On Thu, Oct 14, 2010 at 19:00, Y. S. Ramakrishna <y.s.ramakrishna at oracle.com
> 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

--
Adam Hawthorne
Software Engineer
BASIS International Ltd.
www.basis.com
+1.505.345.5232 Phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20101018/14c7289b/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


More information about the hotspot-gc-dev mailing list