Is CMS cycle can collect finalize objects

[Bharath Mundlapudi]

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. 

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?


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



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

Thanks in anticipation,
-Bharath

________________________________

From: Y. Srinivas Ramakrishna <y.s.ramakrishna at oracle.com>
To: Bharath Mundlapudi <bharathwork at yahoo.com>
Cc: hotspot-gc-use at openjdk.java.net
Sent: Friday, April 15, 2011 9:33 AM
Subject: Re: Is CMS cycle can collect finalize objects

Hi Bharath --

On 4/15/2011 7:12 AM, Bharath Mundlapudi wrote:
> We have tuned our server to not run into Full GC with CMS collector. One thing, we noted recently was - java.lang.ref.Finalizer objects getting incremented with load. Due to this, CMS cycle threshold was reached and CMS went into loop and run continuously.
>
> To verify if CMS is cleaning up these Finalizer objects, I have tested on another setup. I have noticed that Finalizer objects are not getting cleaned but when i force full gc, these objects are getting garbage collected.
>
>
> I have the following questions:
> 1. Is there a way (JVM cmd option) to tell CMS to cleanup Finalizer objects when CMS runs rather than via Full GC?

CMS does process finalizable objects without the need for a full STW gc.
Once an object with a finalizer is determined by the CMS collector to
be unreachable, it will be placed on the finalizable queue, whence
the finalizer thread will pull those objects and finalize them. At the
next CMS cycle the space used by those objects will become available
for new allocation. The only catch is that the CMS collector will
only detect such objects in the old generation (and if you have
enabled class unloading, in the perm generation). (That is not to
say that those in the younger gen will not be finalized; they will
be if both the FinalRef and the referent object are in the young gen
at the time that the referent became unreachable. If they happen to
be split between the two generations (which is unlikely to happen in
practice but is not impossible), then we'll need to wait until
the object that is in the younger generation migrates to the older
generation and then they will be discovered at the next CMS cycle.
(And then there will need to be another CMS cycle to actually reclaim the
space used by them following finalization.)

In your case, what is the symptom? Is the finalizer thread's "to be finalized"
queue of objects growing, or are you saying that the CMS collector does not
detect and enqueue unreachable objects into the finalizer's queue?
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?)


> 2. I see that, we can there is System.runFinalization() method to notify GC to cleanup the finalizer queue. Is this better approach for server-side applications?

runFinalization() will only cause the objects in the finalizer queue to get
finalized in a new thread. If objects are not already on the queue nothing
will happen.

> 3. Is there any JMX API to invoke finalization from an external process?

Don't know.

>
>
> Versions verified:
>
> We are using JDK 1.6.0 update 21/23 on Redhat 5.4.

Did the problem start in 6u21? Or are those the only versions
you tested and found that there was an issue?

Do you have a test case that demonstrates the issue you
encounter? If so, could you send it in and open a suitable bug
report?

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