nullprogram.com/blog/2007/09/14/
Update: I wrote this very long ago as an undergraduate still learning the
basics. Therefore, do not use this or take it seriously. I retain
this article merely as a historical record. It is nothing more than a
novice’s overcomplicated take on region-based memory management.
I read about memory allocation pools in the Subversion manual and
decided to write one for fun. So here it is. Included is a small
driver I ran over night to test for memory leaks. lint
will complain
about memory leaks on this code, however. I also added thread safety,
but I don’t suggest you use it.
A memory allocation pool is good for speeding up a program that needs
to make many small memory requests quickly (many system calls).
Instead, one system call is made in place of many.
It is also useful for semi-automatic memory management. Let’s say you
build some large tree structure somewhere in your program. If you want
to free all this memory used by the tree, you will need to traverse it
to take it down. This takes time and code. If you use a memory pool,
you can free all of the memory at once by freeing the entire memory
pool.
The pool works by allocating a large chunk of memory and dishes it out
as requested (a subpool). If a request is too large to take out of the
current chunk, it allocates another chunk twice as large as the
previous one (another subpool). This doubling allows the pool to
quickly scale up to whatever size is needed. Memory will still be
allocated from the old pool until that pool has too many misses in a
row (hard coded to 10 in my sources). Once this happens, the subpool
remains untouched and your pool will have some slight internal
fragmentation.