Hi,<div><br></div><div>I submitted a patch recently to mitigate the specific CMS problem caused by excessive SocksSocketImpl objects, by trying to avoid creating them in the first place. [1]</div><div>That doesn't solve the general case if there really is a problem with CMS and finalization.</div>
<div><br></div><div>Since we've hit the same problem here, we might investigate further on CMS. I'll report back shall we make progress on it.</div><div><br></div><div>Regards,</div><div>Kris Mok</div><div>Software Engineer, Taobao (<a href="http://www.taobao.com">http://www.taobao.com</a>)</div>
<div><br></div><div>[1]: <a href="http://mail.openjdk.java.net/pipermail/nio-dev/2011-November/001480.html">http://mail.openjdk.java.net/pipermail/nio-dev/2011-November/001480.html</a><br><br><div class="gmail_quote">On Wed, Nov 23, 2011 at 9:31 PM, Jon Masamitsu <span dir="ltr"><<a href="mailto:jon.masamitsu@oracle.com">jon.masamitsu@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Koji,<br>
<br>
There is no engineer assigned to this CR and no progress has been<br>
made on it as far as I can tell.  I'd suggest you pursue this through<br>
your Oracle support contacts.<br>
<font color="#888888"><br>
Jon<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On 11/22/2011 1:06 PM, Koji Noguchi wrote:<br>
> 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>
>> OK, thanks.<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>
>> 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>
>>>>> 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>
>>> Jmap -histo shows the above class is keep accumulating. Infact,<br>
>>> finalizerinfo doesn't show any objects on this process.<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>
>>>>> 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>
>> 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>
>>> Thanks in anticipation,<br>
>>> -Bharath<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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>