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

[Kelvin Nilsen]

On Mon, 22 Sep 2025 19:13:41 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.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove state variable previous GC allocated

I've refactored the code to get rid of the unnecessary state variable: _previous_gc_allocated.  I accomplished by forcing a sample to be taken at the moment we begin GC.  I found that the initial implementation of this change caused unruly behavior because sometimes the allocation data collected between the moment previous sample was taken and the the start of the subsequent GC is too short, and the calculated allocation rate is consequentially too noisy.

The "fix" for this problem is to not force the allocation rate sample if this time is less than 2 ms in duration.  When we ignore the "forced sample request", we treat the "ignored" allocations as if they had been performed after the start of this GC cycle.  Here is the performance of this PR compared to baseline from 8/28 on an Extremem workload with 31 GB heap size.

<img width="2021" height="449" alt="image" src="https://github.com/user-attachments/assets/ca1d5d05-20c3-4e48-89be-51d836dbdf34" />

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

PR Comment: https://git.openjdk.org/jdk/pull/27398#issuecomment-3321410934