Is CMS cycle can collect finalize objects
Srinivas Ramakrishna
ysr1729 at gmail.com
Wed Nov 23 15:11:38 PST 2011
Hi Koji --
Thanks for the test case, that should definitely help with the
dentification of the problem. I'll see if
i can find some spare time to pursue it one of these days (but can't
promise), so please
do open that Oracle support ticket to get the requisite resource allocated
for the official
investigation.
Thanks again for boiling it down to a simple test case, and i'll update if
i identify the
root cause...
-- ramki
On Tue, Nov 22, 2011 at 1:06 PM, Koji Noguchi <knoguchi at yahoo-inc.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111123/150dd794/attachment-0001.html
More information about the hotspot-gc-use
mailing list