Tenuring distribution

Sujit.Das at cognizant.com Sujit.Das at cognizant.com
Mon Aug 3 12:32:28 PDT 2009


The snippet below is for uniform test load in staging environment.
 
Thanks,
Sujit

________________________________

From: Y.S.Ramakrishna at Sun.COM [mailto:Y.S.Ramakrishna at Sun.COM]
Sent: Mon 8/3/2009 2:27 PM
To: Das, Sujit (Cognizant)
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: Tenuring distribution



On 08/ 3/09 12:01 PM, Sujit.Das at cognizant.com wrote:
> Hi All,
> 
> I am trying to look whether there is any scope in improving tenuring
> distribution by changing survivor space or Max Tenuring Threshold. I
> have read some Tenuring distribution examples. But following tenuring
> distribution output of my application confuses me and not sure whether
> the young generation is well-tuned or not. The following tenuring
> distribution O/P is result of consecutive minor collections. It
> increases from age 1 to 3 (sometimes upto age 4) and then drops to age
> 1. It then again increases with each minor collection.

Yes, as you can see, the TT drops to 3 and then to 1, and this
happens because there is periodically a large number of young survivors
(i.e. age 1) in the survivor space, so we pro-actively promote at the
next scavenge to avoid the possibility of premature overflow. You could increase your
survivor space size. (There is clearly some kind of periodic generation
of a large volume of data in your application. You can see whether that
correlates to any kind of load-pulsing, or convoying effects. Are you
using a production load (which can be bursty) or a bursty test load
or a uniform test load for these figures?)

Once again, I think Tony & Charlie's talk slides will help in this kind of
tuning.

-- ramki

> 
> Please do let me know your thoughts.
> 
> Desired survivor size 14188544 bytes, new threshold 4 (max 4)
> - age   1:    7040008 bytes,    7040008 total
> : 305088K->13787K(305088K), 0.0395292 secs]
> 906769K->626948K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 4 (max 4)
> - age   1:    6448424 bytes,    6448424 total
> - age   2:    4461088 bytes,   10909512 total
> : 291163K->12426K(305088K), 0.0191044 secs]
> 904324K->625588K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 3 (max 4)
> - age   1:    7150744 bytes,    7150744 total
> - age   2:    4394936 bytes,   11545680 total
> - age   3:    3582184 bytes,   15127864 total
> : 289802K->19070K(305088K), 0.0191912 secs]
> 902964K->632232K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 1 (max 4)
> - age   1:   18196472 bytes,   18196472 total
> - age   2:    3800224 bytes,   21996696 total
> - age   3:    3340344 bytes,   25337040 total
> : 296446K->27712K(305088K), 0.0282980 secs]
> 909608K->648613K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 4 (max 4)
> - age   1:    5757968 bytes,    5757968 total
> : 305088K->13117K(305088K), 0.0403760 secs]
> 925989K->645051K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 4 (max 4)
> - age   1:    5984000 bytes,    5984000 total
> - age   2:    4197480 bytes,   10181480 total
> : 290493K->13133K(305088K), 0.0251218 secs]
> 922427K->645067K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 3 (max 4)
> - age   1:    6765056 bytes,    6765056 total
> - age   2:    4159752 bytes,   10924808 total
> - age   3:    3534520 bytes,   14459328 total
> : 290509K->17608K(305088K), 0.0258073 secs]
> 922443K->649542K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 1 (max 4)
> - age   1:   17919056 bytes,   17919056 total
> - age   2:    4852200 bytes,   22771256 total
> - age   3:    3152768 bytes,   25924024 total
> : 294984K->27712K(305088K), 0.0303612 secs]
> 926918K->667692K(3044288K)After GC:
> ...
> Desired survivor size 14188544 bytes, new threshold 4 (max 4)
> - age   1:    6579448 bytes,    6579448 total
> : 305088K->13396K(305088K), 0.0386087 secs]
> 945068K->664582K(3044288K)After GC:
> 
> Thanks,
> Sujit
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.
> Any unauthorized review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on
> this e-mail is strictly prohibited and may be unlawful.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use





This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20090804/fb453878/attachment.html 
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


More information about the hotspot-gc-dev mailing list