RFR: 8368015: Shenandoah: fix error in computation of average allocation rate

[William Kemper]

On Fri, 19 Sep 2025 20:36:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We use bytes_allocated_since_gc_start() to compute allocation rates.  This leaves a blind spot, as our current implementation ignores allocations and the time period between the moment we begin GC and the first time we update the allocation rate following the start of GC.  When this happens, we typically find that the sampled number of allocations is smaller than the allocations that had accumulated by the time we triggered the start of the current GC cycle.
> 
> This PR adds tracking for that accounting gap.

Is the real issue that we reset `bytes_allocated_since_gc_start` without sampling the value _before_ it is reset (thereby losing allocations that happen during the gc)? Would it be simpler to also take the sample just before it is reset (perhaps use an atomic exchange with zero, so we lose nothing)? Then we wouldn't need to juggle an extra member variable to remember the value. There is no reason we aren't allowed to update the allocation rate outside of `should_start_gc`.

Side note - should we really call this `bytes_allocated_since_gc_end`? I think that is what the variable actually represents because it is reset at the end of the cycle.

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

PR Review: https://git.openjdk.org/jdk/pull/27398#pullrequestreview-3247194979