Vlinder Software is very happy to announce a new product for embedded software development; the µpool2 memory allocator. Memory allocation and management is the most important bottleneck in embedded software development: most memory allocators cannot be configured or adapted to your needs but must simply be “lived with”. The ability to profile the use of your allocators, make informed decisions on the trade-offs between memory usage and speed requirements and adjust the allocator exactly to your needs is a valuable asset in applications that need to be fast and conservative in their memory

Introducing the Micro-Pool Allocator

The Micro-Pool Allocator, version 2, is a drop-in replacement for your system’s default allocator, implementing the three basic functions of the allocator, malloc, realloc and free, more efficiently. It accomplishes this by using an innovative way of managing small pools of memory, and allowing you to use profiling data to configure every step of the memory management process.

Unique features of the Micro-Pool Allocator

Profile-guided configuration: running your program using the allocator in a default configuration allows you to generate a binary event log containing all the information needed to optimize the configuration of your allocator to suit your specific needs.

Multiple optimization methods from which the most suitable methods can be chosen to suit your needs. Not every optimization method is best for every situation and some are mutually exclusive. Using the binary event log to test different options while profiling the allocator’s behaviour each time allows us to choose the best fit for your application.

Compile-time configuration makes sure that once your application’s behaviour has been determined, run-time monitoring of the allocator is no longer necessary – so the monitoring code is effectively “off” in production code.

Run-time re-configuration: if profiling shows that some application behaviours significantly change your application’s memory management needs, and those behaviours can be detected, the allocator can be told to quickly switch from one configuration to another using a call to a control function. For example: if your application can either parse a large number of XML files requiring a large number of short-lived small objects or perform queries on an in-memory database, requiring a smaller number of larger objects with longer life-spans, the allocator can quickly switch from one set of allocation policies, best suited for parsing the XML files, to another set, better suited for querying the in-memory database.

Contact us for more information!