Is CMS cycle can collect finalize objects

[Krystal Mok]

Hi,

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]
That doesn't solve the general case if there really is a problem with CMS
and finalization.

Since we've hit the same problem here, we might investigate further on CMS.
I'll report back shall we make progress on it.

Regards,
Kris Mok
Software Engineer, Taobao (http://www.taobao.com)

[1]:
http://mail.openjdk.java.net/pipermail/nio-dev/2011-November/001480.html

On Wed, Nov 23, 2011 at 9:31 PM, Jon Masamitsu <jon.masamitsu at oracle.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111123/f74f8ced/attachment-0001.html