Motivation

For what?

Why do we need this project at all? When we have SystemTap, dtrace. And anyway, why do we need allocation statistics?

The goal of the project was to develop a maximally cross-platform tool that allows obtaining very specific statistics of allocations with very specific goals. As it turned out, platform-specific tools either do not allow obtaining these statistics easily, or do not allow obtaining them at all.

Statistics at the libC level, as it turns out, are not collected by almost any cross-platform tools.

The goal of this project was to develop a tool that would be cross-platform, simple and lightweight. These statistics are interesting for many reasons, one of which is the adequate configuration of the parameters of third-party allocators for various purposes.

For this reason, there are no fancy graphs or histograms here. Everything is strictly utilitarian - we display the distribution of allocations by sizes that are multiples of two.

This distribution allows, firstly, to be very surprised at how much our understanding of applications or services memory allocations does not correspond to reality. And, secondly, to use this understanding to improve performance using some third tools and methods.

Historically, there have been many attempts to implement the collection of such statistics (there are a lot of them on StackOverflow), but few were able or willing to bring these attempts to any kind of completion (other than publishing a couple of articles) or getting any kind of finished product at the end. Unlike other similar attempts, this solution is written in C++ and only C++. No C with classes. No assembler. Nothing platform-specific. Only STL, only standard methods.

In any case, I tried to solve this problem as best as I could, as it was necessary for me. For obvious reasons, there is no way to use hooks or attach to running processes (this is system- and platform-specific functionality).

Therefore, this simple library uses interposition of the main allocation functions with the minimum possible overhead (and has algorithmic complexity O(1)).

What is not implemented is either very difficult to implement, or there is no need for it.