Five heaps to choose? - Githubissues

FreeRTOS / FreeRTOS-Kernel

FreeRTOS kernel files only, submoduled into https://github.com/FreeRTOS/FreeRTOS and various other repos.

https://www.FreeRTOS.org

MIT License

2.71k stars 1.11k forks source link

Five heaps to choose? #1014

Closed svenbieg closed 6 months ago

svenbieg commented 6 months ago

I'm missing my heap in every real-time operating system.

Why do You have five? Fast at middle size, slow at middle size, moderate at average speed, slow but small or fast and big?

Please have a look at my memory-manger at https://github.com/svenbieg/Heap!

Why not copy mine?

Best regards,

Sven Bieg

ActoryOu commented 6 months ago

Hi @svenbieg, Thanks for the proposal! Memory Management is the page introducing different heap methods. In summary:

heap_1 - the very simplest, does not permit memory to be freed.
heap_2 - permits memory to be freed, but does not coalescence adjacent free blocks.
heap_3 - simply wraps the standard malloc() and free() for thread safety.
heap_4 - coalescences adjacent free blocks to avoid fragmentation. Includes absolute address placement option.
heap_5 - as per heap_4, with the ability to span the heap across multiple non-adjacent memory areas.

IMHO, these methods are indeed employed in various scenarios. The choice between them ultimately depends on the specific use case. I'll bring this into our discussion.

Thank you.

ActoryOu commented 6 months ago

BTW, could you help draft a post introducing this memory management proposal in FreeRTOS forum for broader community?

Thank you.

RichardBarry commented 6 months ago

Hi - thanks for your interest in FreeRTOS. The kernel intentionally keeps memory allocation as part of the portable layer so developers can choose one of the implementations that comes in the distribution, or just as easily, provide their own. This is done on the understanding that there isn't a single implementation that meets all users needs. You should therefore be able to use your implementation without any issue if it follows the standard malloc and free semantics. As Actory mentions - as as you will have read when opening the issue - we prefer to keep discussions on the support forum so feel free to open a post there.