Proposal: MaxTenuringThreshold and age field size changes

[Y Srinivas Ramakrishna]

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.

-- ramki

> 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 
> small, 
> 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 
> (with 
> 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.
> 
> Nick.