RFR: 8332516: Serial: Refactor how promoted bytes are sampled

[Thomas Schatzl]

On Mon, 20 May 2024 09:05:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple heuristic update around how promoted-bytes are tracked. The real change is in `TenuredGeneration::update_promote_stats`, which uses `used-old-gen` before/after gc to derived promoted-bytes.
> 
> The metric is imprecise in the cases of promotion-failure, because those should be rare. Also, after full-gc, used-old-gen an be decreased; in this case, we'd set promoted bytes as the min value (zero), the best-effort estimate.

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/serial/tenuredGeneration.cpp line 398:

> 396:     promoted_in_bytes = used_after_gc - _used_at_prologue;
> 397:   } else {
> 398:     promoted_in_bytes = 0;

Question about this new code vs. the old code:

So the changed code updates promotion statistics in old gen also during full gc now. The amount of "promotion" is the difference of used in old gen after and before.

I am not sure this is a good idea as the full gc also reduces the amount of existing old gen live objects. Using `0` in that case (if the full gc collects more than the implicit collection of the young gen during full collection) also seems dodgy at best.

If my reading of the code is correct and there isn't a way to correctly measure the amount of live objects in young gen during full gc I would prefer to just not update the promotion counter during full gc.

Also consider "extra" full gcs like System.gc() calls and other causes for full gc that can happen at any time - they only seem to add noise to the promoted bytes sampling.

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

PR Review: https://git.openjdk.org/jdk/pull/19306#pullrequestreview-2084711974
PR Review Comment: https://git.openjdk.org/jdk/pull/19306#discussion_r1618466799