`MemoryCounter` and `VirtualMemory` should be revised.
- `VirtualMemory` in in part atomic and in part not. Peaks are updated atomically, but base values aren't. Which is strange, we either we need atomicity, or we don't.
- `MemoryCounter` is fully atomic
Both classes are used both as backing for live counters and then reused as part of the snapshots.
But we only really need atomicity for the live counters (in MallocMemorySummary and in VirtualMemorySummary). Once we snapshotted the values, there is no need for atomic access, since reporting is done by a single thread.
Moreover, we also don't need the automatic peak updating (`update_peak`) feature in snapshots. It can be actually harmful, since it can falsify the peak values.
Therefore it would be good to re-evaluate the reuse of these classes. Possibly split them into two cases, atomic live counters that keep track of peak accounting, and flat dumb non-atomic counters used in snapshots.
- `VirtualMemory` in in part atomic and in part not. Peaks are updated atomically, but base values aren't. Which is strange, we either we need atomicity, or we don't.
- `MemoryCounter` is fully atomic
Both classes are used both as backing for live counters and then reused as part of the snapshots.
But we only really need atomicity for the live counters (in MallocMemorySummary and in VirtualMemorySummary). Once we snapshotted the values, there is no need for atomic access, since reporting is done by a single thread.
Moreover, we also don't need the automatic peak updating (`update_peak`) feature in snapshots. It can be actually harmful, since it can falsify the peak values.
Therefore it would be good to re-evaluate the reuse of these classes. Possibly split them into two cases, atomic live counters that keep track of peak accounting, and flat dumb non-atomic counters used in snapshots.
- links to
-
Review(master) openjdk/jdk/20550