Proposal: MaxTenuringThreshold and age field size changes

[kirk]

Hi really enjoyed reading Nick's description of how he ran into trouble 
and what he did to fix it.

My preference to delay premature promotions has always been to increase 
the size of survivor spaces. Using larger tenuring thresholds hasn't 
sounded appealing because of the cost of copying. Having GC run less 
often always seemed like a more desirable goal. And I think this is 
especially true in young where it is mostly about live object harvesting 
and having GC run less often gives object a better chance to expire.

If these bits are so important I think that limiting MMT 31 seems 
reasonable at least today. If you have a bit to spare, than 63 seems 
even safer.

Regards,
Kirk Pepperdine

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