RFR (XS): 8200723: Suppress rs_length and predicted_cards sampling during mixed gcs

Thomas Schatzl thomas.schatzl at oracle.com
Mon Apr 16 11:13:51 UTC 2018

Hi all,

  ping for any reviewer ;)


On Wed, 2018-04-04 at 12:35 +0200, 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.
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200723
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8200723/webrev
> Testing:
> hs-tier 1-5 with many other changes over time; manual inspection of
> eden sizing behavior of several known to be affected benchmarks
> Thanks,
>   Thomas

More information about the hotspot-gc-dev mailing list