MaxTenuringThreshold has a new ergonomic value???

[Kirk Pepperdine]

Hi Ramki,

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

Very interesting.. My tactics are based on my observation that copy costs in survivor is normally insignificant to the activities so it pays to keep things out of tenured for as long as you should. To get there, I tend to open every thing up as much as possible (which means setting MaxTenuringThreshold to 15) and then use a graph average survivor occupancies to understand where to set the tenuring threshold (eliminates excess copy costs). IMHO the JVM could do this also and just set the threshold to the flat part of the curve (i.e. slope is 0 or almost 0). What I see graphically when the tenuring threshold is way too low or survivor sizes are too small is that the graph is clipped flat on top. You can't do any analysis with a graph that is machine clipped in this fashion and hence the reason for opening up values.

With ParNew I found that if HotSpot feels the need to rollback the tenuring threshold more than about 15% of the time (combined with a few other heuristics) it's time to step in and fiddle with SurvivorRatio and tenuring thresholds.

I would be very helpful if the PSYoung reported PrintTenuringDistrubution the same way ParNew does.

Regards,
Kirk