Is CMS cycle can collect finalize objects

[Jon Masamitsu]

Koji,

There is no engineer assigned to this CR and no progress has been
made on it as far as I can tell.  I'd suggest you pursue this through
your Oracle support contacts.

Jon



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