This review is from Crev, a distributed system for code reviews. To add your review, set up cargo-crev.

0.8.1 (current) Rating: Positive Thoroughness: Low Understanding: Medium

by kpreid on 2023-10-14

Good characteristics (compared to other instrumented allocators):

  • Allocation numbers are tracked per-thread, which means that it can be used in parallel tests reliably.

Limitations (compared to other instrumented allocators):

  • Not generic; always delegates to the System allocator.
  • Declares #[global_allocator] itself, so whether it is used depends on whether the crate is linked, not on code in the dependent crate.

Bugs noticed during review:

  • Counts failed allocations as if they succeeded.
  • measure(f) does not clean up state if f() panics.
  • If the allocation tracking stack overflows, the counter will be left incremented, which I think will cause future allocations to panic.

None of those bugs affect safety.

I made this review while searching for an instrumented allocator I could use in tests, and others I have evaluated are https://docs.rs/stats_alloc/0.1.10/ and https://docs.rs/logging-allocator/0.1.1/.


Lib.rs has been able to verify that all files in the crate's tarball are in the crate's repository. Please note that this check is still in beta, and absence of this confirmation does not mean that the files don't match.

Crates in the crates.io registry are tarball snapshots uploaded by crates' publishers. The registry is not using crates' git repositories, so there is a possibility that published crates have a misleading repository URL, or contain different code from the code in the repository.

To review the actual code of the crate, it's best to use cargo crev open allocation-counter. Alternatively, you can download the tarball of allocation-counter v0.8.1 or view the source online.