[LLVMdev] Forward: Discussion about custom memory allocators for STL

[Barry Kelly]

Roman Levenstein <romixlev at yahoo.com> wrote:

> There is a discussion thread on llvm-commits list about a possibility of using custom memory allocators for STL to improve the performance and reduce the memory pressure of STL containers, e.g. std::set.
> I thought that this discussion may be interesting for a wider audience and therefore I re-post the messages on llvm-dev as well.
> 
> It would be interesting to hear what others think about 
>  - custom allocators, 

"Normal" memory allocators are a serious pessimization for typical
compiler usage patterns and will waste a fair amount of time and a
non-trivial percentage of space pointlessly keeping track of and freeing
tiny lumps of memory.

Compilers tend to (1) incrementally allocate largeish chunks of
temporary storage for the duration of a deep, probably recursive, call
tree, and want to free it all in one go at the end (with this pattern
being itself recursive), and (2) allocate memory with affinity for a
particular compilation unit, assuming they are doing as much as possible
(parsing, compiling, assembling, linking, etc.) in memory for
efficiency, such that it can in turn be freed en-masse when that
compilation unit is finally through.

Pattern (1) wants a stack-like allocator, with an API resembling
{ void *Allocate(size_t); size_t Mark(); void Reset(size_t mark); void
Free(); }.

Pattern (2) wants something more simple: { void *Allocate(int heapID,
size_t); void Free(int heapID); } (assuming a non-OO API; eliminate
heapID if the thing is an object).

Pattern (2) can be implemented in terms of a generalized pattern (1).

-- Barry

-- 
http://barrkel.blogspot.com/