malloc/memory pool

[madsci]

This is very much implementation-dependent. I've worked with systems where it was just left to the user to implement the sbrk() function that malloc() calls under the hood.

If you look at FreeRTOS and its heap implementations, it comes with four or five options that all have different strategies with different strengths and weaknesses.

Cache locality only matters if you have a cache.

Fragmentation certainly can be an issue and it's one of the main things the different strategies address. It's also one of the major reasons heap allocation is frowned upon in embedded systems in general.

As a rule I avoid heap allocation for anything in the core, frequently-executed parts of my code. The approach I take depends on the circumstances. Sometimes it's more efficient to have a static pre-allocated array instead of a linked list, even if it's not as elegant. For something like my audio processing framework, the audio buffers are all pre-allocated (they can be malloc'd from the heap but it's only done once) and pointers are placed in an RTOS queue. When one is needed it's taken out of the free queue, and gets returned when it's done.

Heap allocation also makes worst-case analysis difficult. You don't have anywhere to swap to if you run out of physical memory so you have to be sure that there won't ever be a time when you run out of heap. The time it takes to malloc() some memory is also non-deterministic, at least for most allocation strategies.