MaxTenuringThreshold available in ParNewGC?

[Kirk Pepperdine]

Hi Li LI,

I fear that you are off in the wrong direction. Resetting tenuring thresholds in this case will never work because they are being calculated to be 1. You're suggesting numbers greater than 1 and so 1 will always be used which explains why you're not seeing a difference between runs. Having a calculated tenuring threshold set to 1 implies that the memory pool is too small. If the a memory pool is too small the only thing you can do to fix that is to make it bigger. In this case, your young generational space (as I've indicated in previous postings) is too small. Also, the cost of a young generational collection is dependent mostly upon the number of surviving objects, not dead ones. Pooling temporary objects will only make the problem worse. If I recall your flag settings, you've set netsize to a fixed value. That setting will override the the new ratio setting. You also set Xmx==Xms and that also override adaptive sizing. Also you are using CMS which is inherently not size adaptable.

Last point, and this is the biggest one. The numbers you're publishing right now suggest that you have a memory leak. There is no way you're going to stabilize the memory /gc behaviour with a memory leak. Things will get progressively worse as you consume more and more heap. This is a blocking issue to all tuning efforts. It is the first thing that must be dealt with.

To find the leak;
Identify the leaking object useing VisualVM's memory profiler with generational counts and collect allocation stack traces turned on. Sort the profile by generational counts. When you've identified the leaking object, the domain class with the highest and always increasing generational count. take an allocation stack trace snapshot and a heap dump. The heap dump should be loaded into a heap walker. Use the knowledge gained from generational counts to inspect the linkages for the leaking object and then use that information in the allocation stack traces to identify casual execution paths for creation. After that, it's into application code to determine the fix.

Kind regards,
Kirk Pepperdine

On 2012-01-11, at 5:45 AM, Li Li wrote:

>   if the young generation is too small that it can't afford space for survivors and it have to throw them to old generation. and jvm found this, it will turn down TenuringThreshold ? 
>    I set TenuringThreshold to 10. and found that the full gc is less frequent and every full gc collect less garbage. it seems the parameter have the effect. But I found the load average is up and young gc time is much more than before. And the response time is also increased.
>    I guess that there are more objects in young generation. so it have to do more young gc. although they are garbage, it's not a good idea to collect them too early. because ParNewGC will stop the world, the response time is increasing.
>    So I adjust TenuringThreshold to 3 and there are no remarkable difference. 
>    maybe I should use object pool for my application because it use many large temporary objects.
>    Another question, when my application runs for about 1-2 days. I found the response time increases. I guess it's the problem of large young generation.
>     in the beginning, the total memory usage is about 4-5GB and young generation is 100-200MB, the rest is old generation.
>     After running for days, the total memory usage is 8GB and young generation is about 2GB(I set new Ration 1:3)
>     I am curious about the heap size adjusting. I found –XX:MinHeapFreeRation and –XX:MaxHeapFreeRation
>    the default value is 40 and 70. the memory manage white paper says if the total heap free space is less than 40%, it will increase heap. if the free space is larger than 70%, it will decrease heap size.
>    But why I see the young generation is 200mb while old is 4gb. does the adjustment of young related to old generation?
>    I read in http://www.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/ young generation should be less than 512MB, is it correct?
> 
> 
> 
> On Wed, Jan 11, 2012 at 1:23 AM, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:
> I recommend Charlie's excellent book as well.
> 
> To answer yr question, yes, CMS + Parew does use MaxTenuringThreshold (henceforth MTT),
> but in order to allow objects to age you also need sufficiently large survivor spaces to hold
> them for however long you wish, otherwise the adaptive tenuring policy will adjust the
> "current" tenuring threshold so as to prevent overflow. That may be what you saw.
> Check out the info printed by +PrintTenuringThreshold.
> 
> -- ramki
> 
> On Tue, Jan 10, 2012 at 1:31 AM, Li Li <fancyerii at gmail.com> wrote:
> hi all
>    I have an application that generating many large objects and then discard them. I found that full gc can free memory from 70% to 40%. 
>    I want to let this objects in young generation longer. I found -XX:MaxTenuringThreshold and -XX:PretenureSizeThreshold.
>    But I found a blog that says MaxTenuringThreshold is not used in ParNewGC.
> And I use ParNewGC+CMS. I tried to set MaxTenuringThreshold=10, but it seems no difference.
> 
> _______________________________________________
> 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120111/20772300/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use