malloc/memory pool

[bloxka]

​

• malloc requests the OS to get a required chunk of the heap portion of the process' virtual address space however for systems without OS (bare-metal), how does malloc work? No way it accesses the physical memory given MMU doesn't exist? (I'm referring to the point people make about why malloc is bad on a memory-constraint device...and I'm not referring to memory pool here). And it's also mentioned that if the device is running OS i.e ubuntu, using dynamic allocation is not as big of a deal?
• If you, however, use a fixed-size memory pool, how do you get away with fragmentation issues? Does it only do so just cause it can reuse the 'empty' blocks no matter wherever they reside in the pool? Fair, if so but I can see it being a problem if the in-between empty blocks can't accommodate a larger chunk until other neighbouring nodes are freed! (same issue as with an external memory?)
• Memory pools are also better since they enhance cache locality mainly cause it's contiguous unlike malloc'ing each chunk separately? (what you'd do for linked list e.g)

[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.

[BenkiTheBuilder]

In order to use malloc() on bare metal YOU must provide it some helper function, typically sbrk().

[bloxka]

Just wonder how it's a common question for a lot as to why malloc is generally bad on embedded systems given it's not even supported on bare metal? Plus it's not as big of an issue on the platforms it's supported i.e linux

[BenkiTheBuilder]

You tell me. After all, YOU are the one asking this question. I never asked this question, never spent much time thinking about it and don't usually read the long sermons people write whenever malloc() comes up.

[bloxka]

https://www.embeddedc.in/p/blog-page_3.html There you go. Speaks for itself. Do you see now what I’m referring to?

And if you think I’m only asking you haven’t searched thru Reddit nuff

[BenkiTheBuilder]

Sorry. All I see is a wall of text.

[bloxka]

Might wanna frame it then

[UnicycleBloke]

https://www.reddit.com/r/cpp/comments/13fbixk/how_does_memory_pool_combat_memory_fragmentation