Is CMS cycle can collect finalize objects

Thu Nov 24 07:28:11 UTC 2011

Hi Jon,

If I can solve the problem locally, what is the chance of getting it into a build?

Regards,
Kirk

On Nov 23, 2011, at 2:31 PM, Jon Masamitsu wrote:

> 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

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use