Proposal: MaxTenuringThreshold and age field size changes

[Jon Masamitsu]

Jon Masamitsu wrote:
> 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.

Sorry, guys.  That should have been 4 bits.  You can
stop wondering where that heck I got 15 bits now.

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