Memory pool

Memory pools, also called fixed-size-blocks allocation, allow dynamic memory allocation comparable to malloc or C++'s operator new. As those implementations suffer from fragmentation because of variable block sizes, it can be impossible to use them in a real time system due to performance. A more efficient solution is preallocating a number of memory blocks with the same size called the memory pool. The application can allocate, access, and free blocks represented by handles at run time.

Many real-time operating systems use memory pools, such as the Transaction Processing Facility.

Some systems, like the web server Nginx, use the term memory pool to refer to a group of variable-size allocations which can be later deallocated all at once. This is also known as a region; see region-based memory management.

Sample memory pool implementation

A simple memory pool module can allocate for example 3 pools at compile time with block sizes optimized for the application which deploys the module. The application can allocate, access and free memory with the following interface:

• To allocate memory from the pools. The function will determine the pool, where the required block fits in. If all blocks of that pool are already reserved, the function tries to find one in the next bigger pool(s). An allocated memory block is represented with a handle.
• To get an access pointer to the allocated memory.
• To free the formerly allocated memory block.
• The handle can for example be implemented with an unsigned int. The module can interpret the handle internally by dividing it into pool index, memory block index and a version. The pool and memory block index allow fast access to the corresponding block with the handle, while the version, which is incremented at each new allocation, allows detection of handles whose memory block is already freed (caused by handles retained too long).

Memory pool vs malloc

Benefits

• Memory pools allow memory allocation with constant execution time (no fragmentation). The memory release for thousands of objects in a pool is just one operation, not one by one if malloc is used to allocate memory for each object.
• Memory pools can be grouped in hierarchical tree structures, which is suitable for special programming structures like loops and recursions.
• Fixed-size block memory pools do not need to store allocation metadata for each allocation, describing characteristics like the size of the allocated block. Particularly for small allocations, this provides a substantial space savings.
• Memory pools will automatically grow in size to accommodate programs which require more memory than the original pool contained, until of course there is no more memory available on the system.
• Sometime memory pools are not ideal for some applications, but they are extremely useful in Subversion. As a Subversion developer, you'll need to grow comfortable with pools and how to wield them correctly.
• In memory pools, memory usage bugs and bloating can be difficult to diagnose and fix regardless of the API, but the pool construct provided by APR has proven a tremendously convenient, time-saving bit of functionality.

Drawbacks

• Memory pools may need to be tuned for the application which deploys them.

See also

• Memory Pool System
• Free list

References

• Programming with Memory Pools

External links

• PJLIB Reference: Fast Memory Pool
• Pool Concepts
• A Memory Allocator