Is CMS cycle can collect finalize objects

[Koji Noguchi]

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