RFR (M): 8069330: Adjustment of concurrent refinement thresholds does not take hot card cache into account

[Thomas Schatzl]

Hi all,

  can I have reviews for this change that fixes one part of the
concurrent refinement threshold calculation?

The problem is that the update RS time is used as a whole to determine
the refinement thresholds to calculate a cost of scanning/updating
cards. It does so by dividing the actual update RS time by the number of
cards processed during that time.

This is not true. In addition to processing cards, g1 also clears the
hot card cache.

That means that number of cards value is too small, making the cost per
card too high, making the prediction to be too small.

Further, if the hot card cache is sized larger than default, it may take
up more time than the time available for update RS. That makes the
prediction basically returning numbers that do not have anything to do
with reality.

This is not indicated by G1 at all.

So this change adds timing information for the scan HCC phase (using
PrintGCDetails), informs the user that something is wrong here if the
HCC is too large or the available time too small, and uses that
information to get the cost per card calculation right.

While in itself this change does not help a lot since refinement
threshold calculations are pretty bad (JDK-8137022) and there are bugs
in refinement thread management (JDK-8133051) that make g1 waste a lot
of cpu time, this change in conjunction with some prototypes for the
others gives very good results.

CR:
https://bugs.openjdk.java.net/browse/JDK-8069330
Webrev:
http://cr.openjdk.java.net/~tschatzl/8069330/webrev/
Testing:
jprt

Thanks,
  Thomas