You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allocation tracker did not deal with possibility that counters could reach `usize::MAX`. In this case, addition would wrap around back to 0.
This problem was pointed out by @aapoalas in #13043 (review).
Introduce an `AtomicCounter` type which uses saturating addition, to prevent this happening.
Reaching such a high allocation count is highly unlikely on 64-bit systems, but might just about be possible on 32-bit.
Maybe this is overkill, but since `cargo allocs` is just an internal tool, performance is not the highest priority. So I figure on balance probably better to handle this edge case. It doesn't seem to hurt perf much.
```
# Before
% hyperfine -i --warmup 3 'cargo allocs'
Benchmark 1: cargo allocs
Time (mean ± σ): 299.9 ms ± 2.4 ms [User: 132.8 ms, System: 31.0 ms]
Range (min … max): 297.6 ms … 303.9 ms 10 runs
# After
% hyperfine -i --warmup 3 'cargo allocs'
Benchmark 1: cargo allocs
Time (mean ± σ): 301.3 ms ± 3.4 ms [User: 133.3 ms, System: 31.5 ms]
Range (min … max): 297.8 ms … 310.0 ms 10 runs
```
Note: The same problem in arena allocation tracker is addressed in #13043.
0 commit comments