Object stats

[mjp41]

This adds some statistic for tracking

• How many deallocations are in message queues.
• How many allocators have been created.
• Per sizeclass statistics
  • Number of objects allocated
  • Number of objects deallocated
  • Number of slabs allocated
  • Number of slabs deallocated

The per sizeclass statistics are tracked per allocator, and a racy read is done to combine the results for displaying.

These statistics were used to debug #615 to calculate the fragmentation.

The displayed statistics are intended for post processing to calculate the fragmentation/utilisation.

The interface just prints the results using message. This could be improved with a better logging infrastructure.

[nwf-msr]

Comments so far; posting before switching threads.

[nwf-msr]

Generally looks quite nice. ISTR snmalloc of old had the ability to conditionally keep stats or not; perhaps it would be worth having an empty implementation of the Stat and MonotoneStat interfaces and either templating or having a namespace snmalloc-scoped using to pick between them?

[nwf-msr]

Something has happened (TM) with the syntax there. Can this be a SNMALLOC_ASSERT_MSG?

[nwf-msr]

Generally looks quite nice. ISTR snmalloc of old had the ability to conditionally keep stats or not; perhaps it would be worth having an empty implementation of the Stat and MonotoneStat interfaces and either templating or having a namespace snmalloc-scoped using to pick between them?

[mjp41]

Generally looks quite nice. ISTR snmalloc of old had the ability to conditionally keep stats or not; perhaps it would be worth having an empty implementation of the Stat and MonotoneStat interfaces and either templating or having a namespace snmalloc-scoped using to pick between them?

I was going to profile to see how much the operations cost. If they are noticeable, then I will macro it away as you suggest.

[mjp41]

So I have benchmarked this, and it has a perf regression. The worst case seems to be 3% (glibc-thread), but most tests are below 1%. I am going to investigate moving more of the statistics off the fast path.

This will basically be,

1. assuming everything in current fast free list has been allocated up front, so individual allocations don't need to do accounting.
2. on frees only update the count for a slab when we hit a slow path, or that free list is taken to be used as a fast free list.

This will over approximate the current user allocations quite a bit, but should make the overhead practically zero.

Alternatively, we could look at making this a compile time option.