Proposal: MaxTenuringThreshold and age field size changes
Jon.Masamitsu at Sun.COM
Wed Jun 4 17:59:31 PDT 2008
Since higher MTT's are important for some applications
and we really don't know how high is high enough, should
we take John P's suggestion a step further and use the
upper 15 bits of any MTT as the tenuring age (i.e.,
setting MTT to 60, 61, 62 or 63 would tenure at
age 60)? We just have to increment the age every
n-th scavenge as appropriate.
Y Srinivas Ramakrishna wrote On 06/04/08 14:54,:
>Hi Nick --
>thanks for sharing that experience and for the nice description!
>Looking at the PrintTenuringDistribiution for your application
>with the old, 5-age bit JVM run with MTT=24 would probably be
>illuminating. By the way, would you expect the objects surviving
>24 scavenges (in that original configuration) to live for a pretty long time?
>Do you know if your object age distribution has a long thin tail,
>and, if so, where it falls to 0? If it is the case that most applications
>have a long thin tail and that the population in that tail (age > MTT)
>is large, then NeverTenure is probably a bad idea.
>As you found, the basic rule is always that if a small transient overload
>causes survivor space overflow, that in turn can cause a much longer-term "ringing effect"
>because of "nepotism" (which begets more nepotism, ....,) the effects of
>which can last much longer than the initial transient that set it off.
>And, yes, NeverTenure will lead to overflow in long-tailed distributions
>unless your survivor spaces are large enough to accomodate the tail;
>which is just another way of saying, if the tail does not fit, you will
>have overflow which will cause nepotism and its ill-effects.
>Thanks again for sharing that experience and for the nice
>explanation of your experiments.
>>So, as a conclusion: Yes, we are missing the 5th age bit. NeverTenure
>>works very bad for us. MTT=15 with our original eden size is too
>>but increasing the eden size allows us to get similar behavior with
>>MTT=15 as with the original configuration (MTT=24 and 5 age bits).
>>I think, Tony's suggestion to limit the configurable MTT to 2^n-1
>>n being the age bits) is a good solution. At least according to my
>>tests, this is much better then activating the "never tenure" policy
>>when the user is not aware of this.
>>I hope some of this may have been helpful for you. I will send some more
>>detailed results and logfiles directly to Tony.
More information about the hotspot-gc-dev