[jdk11u-dev] RFR: 8228609: G1 copy cost prediction uses used vs. actual copied bytes [v6]

[Yude Lin]

On Thu, 7 Apr 2022 14:58:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This change is very different from the original one, but fixing it in 11u sounds feasible to me. We'll test it. Do you have a specific test case which allows observing unstable gc frequency?

We observed this in an application. With additional logging, we can observe the miscalculation from, e.g., test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegions.java

The current way to get copied_bytes will result in negative value. I had

..
[0.708s][error][gc] GC(186) cset.used=14641416, freed_bytes=40855816, copied_bytes=-26214400, actual_copied_bytes=0
[0.714s][error][gc] GC(188) cset.used=14641416, freed_bytes=40855816, copied_bytes=-26214400, actual_copied_bytes=0
[0.720s][error][gc] GC(190) cset.used=14641416, freed_bytes=40855816, copied_bytes=-26214400, actual_copied_bytes=0
[0.726s][error][gc] GC(192) cset.used=14641416, freed_bytes=40855816, copied_bytes=-26214400, actual_copied_bytes=0
[0.732s][error][gc] GC(194) cset.used=14641416, freed_bytes=40855816, copied_bytes=-26214400, actual_copied_bytes=0
[0.738s][error][gc] GC(196) cset.used=14641416, freed_bytes=40855816, copied_bytes=-26214400, actual_copied_bytes=0
[0.744s][error][gc] GC(198) cset.used=14641416, freed_bytes=40855816, copied_bytes=-26214400, actual_copied_bytes=0

copied_bytes is negative because it is deduced from ``size_t copied_bytes = _collection_set->bytes_used_before() - freed_bytes;``, and ``_collection_set->bytes_used_before()`` didn't consider eager-reclaimed humongous, so it appears to be much smaller than ``freed_bytes``.

There currently is an if condition ``if (_collection_set->bytes_used_before() > freed_bytes)`` to prevent we from getting a negative value. So the current code simply doesn't report the data to the analytics.

Not reporting is fine. At worst we lose some data points. But it can also happen that we get a positive, near-zero ``copied_bytes``. It will make the value ``double cost_per_byte_ms = average_copy_time / (double) copied_bytes;`` very big. This causes young generation to shrink.

-------------

PR: https://git.openjdk.java.net/jdk11u-dev/pull/927