MaxTenuringThreshold has a new ergonomic value???

[Srinivas Ramakrishna]

On Tue, Sep 3, 2013 at 12:24 AM, Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
> Hi,
>
> On Mon, 2013-09-02 at 11:58 +0200, Kirk Pepperdine wrote:
>> Hi,
>>
>> Where does ergonomics calculate MaxTenuringhreshold for ParNew? It seems
>>that I missed the memo that the default ergonomics setting for this
>>flag has drifted from 4 to 6? Is this now the case?
>
> arguments.cpp, Arguments::set_cms_and_parnew_gc_flags():
>
> 1218:   intx   tenuring_default = (intx)6;
> [...]
> 1286:  // Unless explicitly requested otherwise, definitely
> 1287:  // promote all objects surviving "tenuring_default" scavenges.
> 1288:  if (FLAG_IS_DEFAULT(MaxTenuringThreshold) &&
> 1289:      FLAG_IS_DEFAULT(SurvivorRatio)) {
> 1290:    FLAG_SET_ERGO(uintx, MaxTenuringThreshold, tenuring_default);
> 1291:  }
>
>
> Note that the most recent change in line 1218 of that file dates back to
> March 2011.
>
> I do not know the rationale for this change.

Basically, the original code used 4 or 0 (low values) because the idea
for low-pause concurrent old gen collectors
was that you shift the GC load over to the old gen collector which
would hopefully do a good job of collecting medium-lived
garbage. 0 was soon proved to be a bad value, hence the move to a more
sensible value of 4 to filter very short-lived objects,
yet avoid copying too much in a minor gc, hence the hard limit of 4.
As time marches on, you can probably squeeze more and more work into a
given absolute pause time budget, so one
could probably have the young gen collector do more copying work while
still giving low pauses. Hence the increase to 6.
You may be right that it could perhaps be increased further, may be by
one notch every two years (a kind of corollary to Moore's law,
if you will). But I think Kirk is right that instead of the draconian
limit on tenuring threshold, it might be better to set a certain
survivor ratio and let MTT be 15. It's all a bit of a heuristic about
how the user will tune, and obviously this was just another
heuristic.

-- ramki

>
> The RFR does not give additional details:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-March/002384.html
>
> Hth,
> Thomas
>