Proposal: MaxTenuringThreshold and age field size changes

[Y Srinivas Ramakrishna]

> This is mostly because there isn't a well known tool that will suggest 
> a 
> change in the MTT. IMHO, having lower MTT values is less useful than 
> having higher ones. I rarely want to prematurely promote where as I 
> often would like to delay promotion.

I agree. And for that reason it might make sense to leave MTT untouched
at the system-selected default of 2^n -1, n the extant age bits in a release,
if you do not want objects promoted sooner for other reasons.
For that reason, Tony's proposal of letting any user-selected
value greater than 2^n -1, saturate at 2^n -1 is a very welcome change that
would protect against inadvertent mistuning (or of changes in "n" in the underlying
implementation, as happened in 5u5->5u6).

[As Tony noted, the key is to _always_ (unless the user explicitly requested NeverTenure
in which case all bets may be off) try to avoid premature promotion because of survivor space overflow
(the statement is deliberately fuzzy because the multi-threaded nature of
scavenges and/or sudden changes in object demographics can collude against any
kind of guarantee in the face of fixed size survivor spaces).]

Along with, as Jon pointed out, of making {Always,Never}Tenure work uniformly
with all collectors.

-- ramki