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

[William Kemper]

On Fri, 19 Sep 2025 21:56:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> There is some inherent synchronization in place that avoids the need for an atomic variable.

I meant losing updates to `bytes_allocated_since_gc_start` made by mutators as they allocate. This read/reset could _technically_ lose updates from allocating threads (I'm not really worried about that):
```C++
    size_t bytes_allocated = young_generation()->bytes_allocated_since_gc_start();
    // Suppose control thread is off cpu here while mutators increase bytes allocated
    young_generation()->reset_bytes_allocated_since_gc_start();


I had something like this in mind:
```C++
  // atomic exchange existing value with zero
  size_t bytes_allocated = young_generation()->reset_bytes_allocated_since_gc_start();
  // incorporate the value into the samples for the average
  young_generation()->sample_allocations(bytes_allocated);


> I believe we do reset at the start of GC. 

You're right, I misread that code. I think I'm more confused now than I was before. I thought you were trying to fix the lost updates to `bytes_allocated_since_gc_start` between the last time the heuristic reads it and resets it. Shouldn't the average allocation rate work out the same if we read small changes frequently (the usual case when the GC is idle) or if we read a large change infrequently (such as our first read after it is reset)?

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

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