I\'ve heard about people using custom memory allocators for their project, particulary in C++.
What is a custom memory allocator, compared to malloc?
Memory allocators are used as optimizations for speed. Allocations by the Operating system are slow. So your own memory manager grabs a large bucket of memory, and then makes the allocations for you from that memory bucket without going through the OS. This technique is more frequently used in games/consoles/embeded systems.
http://www.memorymanagement.org/articles/
http://www.ibm.com/developerworks/aix/tutorials/au-memorymanager/au-memorymanager-pdf.pdf
There's an extensive description of custom allocators, along with their empirical evaluation, in the following paper (that I co-wrote). Before you decide to use custom allocators in your C++ project, you should give this paper a read. The executive overview is a good general-purpose allocator is better (faster and more space-efficient) than all styles of custom allocators except regions, but these have serious problems.
Reconsidering Custom Memory Allocation (ACM link, direct PDF link, Powerpoint talk slides), OOPSLA 2002.
Programmers hoping to achieve performance improvements often use custom memory allocators. This in-depth study examines eight applications that use custom allocators. Surprisingly, for six of these applications, a state-of-the-art general-purpose allocator (the Lea allocator) performs as well as or better than the custom allocators. The two exceptions use regions, which deliver higher performance (improvements of up to 44%). Regions also reduce programmer burden and eliminate a source of memory leaks. However, we show that the inability of programmers to free individual objects within regions can lead to a substantial increase in memory consumption. Worse, this limitation precludes the use of regions for common programming idioms, reducing their usefulness.We present a generalization of general-purpose and region-based allocators that we call reaps. Reaps are a combination of regions and heaps, providing a full range of region semantics with the addition of individual object deletion. We show that our implementation of reaps provides high performance, outperforming other allocators with region-like semantics. We then use a case study to demonstrate the space advantages and software engineering benefits of reaps in practice. Our results indicate that programmers needing fast regions should use reaps, and that most programmers considering custom allocators should instead use the Lea allocator.
A custom memory allocator is a replacement for malloc
(actually, usually a replacement for operator new
) that retrieves blocks of bytes in some fashion other than the default. malloc
is not the lowest level you can go, because malloc
itself is implemented in terms of even simpler primitives from the OS that allocate blocks of memory for partitioning.
Common use cases for making custom allocators are optimizing for allocations of small objects (the default allocator is usually really bad at this), allocating in a way that guarantees good locality (by allocating objects near one another), allocating with logging/tracking (to diagnose leaks), allocating from a garbage-collected resource pool, etc. There are a lot of different options available, and many programs can squeeze out a bit more performance using these custom allocators.
A memory allocator isn't lower level than malloc
. (The default allocator typically calls malloc
directly or indirectly)
An allocator just allows you to specify different allocation strategies. For example, you might use an allocator which calls malloc
once to retrieve a large pool of memory, and then for subsequent allocation requests, it just returns a small chunk of this pool.
Or you may use it as a hook to allow you to perform some additional task every time memory is allocated or freed.
As to your second question, malloc
is the lowest you can go without losing portability. malloc
is typically implemented using some OS-specific memory allocation function, so that would be lower level still. But that's unrelated to your main question, since C++ allocators are a higher-level abstraction.
malloc() is a library function in libc (or glibc) that makes a system call sbrk() when it needs to actually allocate more memory to the process. Together, malloc() and free() manage a list of memory blocks that are used when malloc(), calloc() etc. are called.
You can use a custom allocator when malloc()'s behavior isn't desired or you want to do additional work on top of malloc/free.