RFR (XS): 8200723: Suppress rs_length and predicted_cards sampling during mixed gcs
stefan.johansson at oracle.com
Mon Apr 16 12:51:20 UTC 2018
On 2018-04-04 12:35, Thomas Schatzl wrote:
> Hi all,
> can I have reviews for this small change that fixes a throughput
> problem G1 may show after mixed gc phase?
> The problem is that after mixed gc young gen sizing is heavily
> influenced by mixed gc due to in many cases highly different RS lengths
> and number of cards processed. Almost always in a negative way (if not
> neutral), i.e. during mixed gc these values are almost always much
> higher than during young gc, meaning that young gen of the first few
> young-only gcs is much smaller than it should be.
> There is another related problem with adaptive IHOP, where due to these
> changes to the young gen, the survival rate increases (smaller young
> gen means less time to die), which decreases IHOP, which in turn
> increases the number of mixed phases (e.g. mixed gc's), which in turn
> make young gen stay small.
> JDK-8035557 has a graph showing how eden size over time in relation to
> rs_length could look like without this change.
> Contrary to JDK-8035557 this change kind of arbitrarily suppresses the
> sampling for rs_length and predicted_cards during mixed gc, so these
> "bad" values never enter the prediction logic. Mixed gc is not
> affected, since we do not use any prediction for sizing young during
> that time.
> The proper fix would be JDK-8035557, completely separating predictions
> for young-only and mixed gc.
Yet another one you slipped past me :)
I think the reasoning around this change is sound and code-wise it looks
simple and good.
> hs-tier 1-5 with many other changes over time; manual inspection of
> eden sizing behavior of several known to be affected benchmarks
More information about the hotspot-gc-dev