Hi Koji --<br><br>Thanks for the test case, that should definitely help with the dentification of the problem. I'll see if<br>i can find some spare time to pursue it one of these days (but can't promise), so please<br>
do open that Oracle support ticket to get the requisite resource allocated for the official<br>investigation.<br><br>Thanks again for boiling it down to a simple test case, and i'll update if i identify the<br>root cause...<br>
<br>-- ramki<br><br><div class="gmail_quote">On Tue, Nov 22, 2011 at 1:06 PM, Koji Noguchi <span dir="ltr"><<a href="mailto:knoguchi@yahoo-inc.com">knoguchi@yahoo-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
This is from an old thread in 2011 April but we're still seeing the same<br>
problem with (nio) Socket instances not getting collecting by CMS.<br>
<br>
Opened <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113118" target="_blank">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113118</a><br>
<br>
Thanks,<br>
Koji<br>
<br>
<br>
(From<br>
<a href="http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2011-April/subject.htm" target="_blank">http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2011-April/subject.htm</a><br>
l)<br>
On 4/25/11 8:37 AM, "Y. Srinivas Ramakrishna" <<a href="mailto:y.s.ramakrishna@oracle.com">y.s.ramakrishna@oracle.com</a>>><br>
wrote:<br>
> On 4/25/2011 9:10 AM, Bharath Mundlapudi wrote:<br>
> > Hi Ramki,<br>
> ><br>
> > Thanks for the detailed explanation. I was trying to<br>
> > run some tests for your questions. Here are the answers to some of your<br>
> > questions.<br>
> ><br>
> >>> What are the symptoms?<br>
> > java.net.SocksSocketImpl objects are not getting cleaned up after a CMS<br>
> cycle. I see the direct<br>
> > correlation to java.lang.ref.Finalizer objects. Overtime, this fills up<br>
> > the old generation and CMS going in loop occupying complete one core.<br>
> > But when we trigger Full GC, these objects are garbage collected.<br>
><br>
> OK, thanks.<br>
><br>
> ><br>
> > You<br>
> >   mentioned that CMS cycle does cleanup these objects provided we enable<br>
> > class unloading. Are you suggesting -XX:+ClassUnloading or<br>
> > -XX:+CMSClassUnloadingEnabled? I have tried with later and<br>
> ><br>
> > didn't<br>
> >   succeed.  Our pern gen is relatively constant, by enabling this, are we<br>
> >   introducing performance overhead? We have room for CPU cycles and perm<br>
> > gen is relatively small, so this may be fine. Just that we want to see<br>
> > these objects should GC'ed in CMS cycle.<br>
> ><br>
> ><br>
> > Do you have any suggestion w.r.t. to which flags should i be using to<br>
> trigger this?<br>
><br>
> For the issue you are seeing the -XX:+CMSClassUnloadingFlag will<br>
> not make a difference in the accumulation of the socket objects<br>
> because there is no "projection" as far as i can tell of these<br>
> into the perm gen, esepcially since as you say there is no class<br>
> loading going on (since your perm gen size remains constant after<br>
> start-up).<br>
><br>
<br>
> However, keeping class unloading enabled via this flag should<br>
> hopefully not have much of an impact on your pause times given that<br>
> the perm gen is small. The typical effect you will see if class<br>
> unloading is enabled is that the CMS remark pause times are a bit<br>
> longer (if you enable PrintGCDetails you will see messages<br>
> such as "scrub string table" and "scrub symbol table", "code cache"<br>
> etc. BY comparing the CMS-remark pause details and times with<br>
> and without enabling class unloading you will get a good idea<br>
> of its impact. In some cases, eben though you pay a small price<br>
> in terms of increased CMS-remark pause times, you will make up<br>
> for that in terms of faster scavenges etc., so it might well<br>
> be worthwhile.<br>
><br>
> In the very near future, we may end up turning that on<br>
> by default for CMS because the savings from leaving it off<br>
> by default are much smaller now and it can often lead to<br>
> other issues if class unloading is turned off.<br>
><br>
> So bottom line is: it will not affect the accumulation of<br>
> your socket objects, but it's a good idea to keep class<br>
> unloading by CMS enabled anyway.<br>
><br>
> ><br>
> ><br>
> >>> What does jmap -finalizerinfo on your process show?<br>
> >>> What does -XX:+PrintClassHistogram show as accumulating in the<br>
> heap?<br>
> >>> (Are they one specific type of Finalizer objects or all<br>
> varieties?)<br>
> ><br>
> > Jmap -histo shows the above class is keep accumulating. Infact,<br>
> > finalizerinfo doesn't show any objects on this process.<br>
><br>
> OK, that shows that the objects are somehow not discovered by<br>
> CMS as being eligible for finalization. Although one can imagine<br>
> a one cycle delay (because of floating garbage) with CMS finding<br>
> these objects to be unreachable and hence eligible for finalization,<br>
> continuing accumulation of these objects over a period of time<br>
> (and presumably many CMS cycles) seems strange and almost<br>
> definitely a CMS bug especially as you find that a full STW<br>
> gc does indeed reclaim them.<br>
><br>
> ><br>
> ><br>
> ><br>
> >>> Did the problem start in 6u21? Or are those the only versions<br>
> >>> you tested and found that there was an issue?<br>
> > We<br>
> >   have seen this problem in 6u21. We were on 6u12 earlier and didn't run<br>
> > into this problem. But can't say this is a build particular, since lots<br>
> > of things have changed.<br>
><br>
> Can you boil down this behavior into a test case that you are able<br>
> to share with us?<br>
> If so, please file a bug with the test case<br>
> and send me the CR id and I'll take a look.<br>
><br>
> Oh, and before you do that, can you please check the latest public<br>
> release (6u24 or 6u25?) to see if the problem still reproduces?<br>
><br>
> thanks, and sorry I could not be of more help without a bug<br>
> report or a test case.<br>
><br>
> -- ramki<br>
><br>
> ><br>
> > Thanks in anticipation,<br>
> > -Bharath<br>
> ><br>
<br>
<br>
<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
</blockquote></div><br>