<div>On Thu, Oct 14, 2010 at 19:00, Y. S. Ramakrishna <span dir="ltr"><<a href="mailto:y.s.ramakrishna@oracle.com">y.s.ramakrishna@oracle.com</a>></span> wrote:</div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Hi Adam --<br>
<br>
...<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


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.<br>


</blockquote>
<br></div>
Yes, scavenges do process unreachable Reference objects found in the young gen.<br>
However, once these get into the old gen, you are right that you will need a<br>
CMS cycle to identify them as unreachable and to process them appropriately.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
    Here's an excerpt from the "workaround" section of that bug<br></div><div class="im">
   ... </div></blockquote></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">
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.<br>


</div></blockquote>
<br>
Precisely. The two are actually additive, but either by itself may not<br>
be sufficient, and as you pointed out (1) may not even be always feasible.<div class="im">...</div>
-- ramki<br></blockquote><div><br></div><div><br></div><div><div>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<div>

<br></div><div>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.</div>

<div><br></div><div>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.</div></div><div><br></div><div>I ran some tests with G1 today, but I'll post a separate thread about that.</div>

<div><br></div><div>Thanks for the help.</div><div><div><br></div>Adam<br><br>--<br>Adam Hawthorne<br>Software Engineer<br>BASIS International Ltd.<br><a href="http://www.basis.com">www.basis.com</a><br>+1.505.345.5232 Phone<br>

<br><br></div></div><div> </div></div></div>