PMMM - The Poor Man's Memory Monitor
		was written by Burton M. Strauss III (BStrauss@acm.org)

What and How

PMMM uses #defines to replace calls to malloc and associated routines with our routines (the "shim").

That's pretty standard - in fact it's cribbed from Ntop's pre-existing memory leak trapping code. I just didn't like it's method of mallocing another block to track each allocation. If memory is tight, allocating more doesn't seem - to me - to be a good idea.

Using PMMM was designed to be (and is) almost trivially simple from the developer's perspective - just add

#include "pmmm.h"

The PMMM routines invoke the underlying system malloc, and are followed by code to record information about the memory allocation in a small static-sized table (the size is set at compile time). The table records the size, address and where the memory was allocated from (the compiler passes us that, using the __FILE__ and __LINE__ pseudo-variables. At the cost of a few bytes per entry, we flag how it was allocated/freed (c- for calloc, etc.)

Really, all the information is in the call, except the size of the block being freed or reallocated. To track frees, all we would need is the address of the memory block from the previous allocation. If we find a match with the pointer we're being asked to free, we know how much memory was allocated.

However, a table like that could get pretty big, pretty fast. So we needed some limits. To limit memory usage, we track only the larger allocations (you choose what "large" is).

If we run out of entries or can't map a pointer back to an allocated block, we just ignore it - accepting a small level of inaccuracy for speed and simplicity.

Add a couple of routines to print out the information and poof...

That's the basic PMMM.

On to the pre-history of PMMM.