# Thoughts on memory management

**URL:** <https://forums.freertos.org/t/thoughts-on-memory-management/85>\
**Category:** Kernel\
**Created:** [June 12, 2011, 1:48pm UTC](https://forums.freertos.org/t/thoughts-on-memory-management/85 "2011-06-12T13:48:32Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [June 12, 2011, 1:48pm UTC](https://forums.freertos.org/t/thoughts-on-memory-management/85/1 "2011-06-12T13:48:32Z")

</div>

**[anguel78](https://sourceforge.net/u/anguel78/)** wrote on [Sunday, June 12, 2011](https://sourceforge.net/p/freertos/discussion/382005/thread/03704314/#c3ca):

Hi!

In this forum I often read the recommendation to use heap\_ **3**.c as soon as any task (I am not talking about the kernel) needs to call malloc() or free() itself. When using heap\_3.c one should probably also replace any calls to malloc() and free() with the thread-safe versions pvPortMalloc() and vPortFree().

But I wonder if there isn’t still a benefit in using the simple heap\_ **1**.c instead of the complex heap\_3.c when I don’t need to dynamically create / delete tasks, queues, etc.? The Memory Management chapter of FreeRTOS states that using heap\_3.c “ **will probably considerably increase the kernel code size** ”. If this is the case, I would prefer to use heap\_1.c and just make the tasks (not the kernel) use the thread-safe pvPortMalloc() and vPortFree(). Right?

If I have only a **single** task that needs to call malloc() and free() it would be probably even possible to use the original malloc() and free() for that task when using heap\_1.c, because there is no need for reentrancy. The kernel would not need to be suspended in this case anymore, as nothing but this single task would ever touch the heap, so this task could be safely preempted at any time.

Any comments are welcome…

Greetings,  
Anguel

---

<div class="post-metadata">

**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\
**Post date:** [June 12, 2011, 6:25pm UTC](https://forums.freertos.org/t/thoughts-on-memory-management/85/2 "2011-06-12T18:25:06Z")

</div>

**[richard\_damon](https://sourceforge.net/u/richard_damon/)** wrote on [Sunday, June 12, 2011](https://sourceforge.net/p/freertos/discussion/382005/thread/03704314/#d35c):

I believe the increase in kernel code size for using heap\_3.c is due to the inclusion of malloc/free in the code, if you are already including it for other purposes, than using heap3 likely takes LESS space than heap\_1/2.c since heap\_3.c is itself very simple. Having the kernel use heap\_3.c also adds a bit of efficiency to memory usage, as you don’t lose the part of the heap\_1/2 space not used from the rest of the program.

Also note, you can NOT mix heap\_1 and heap\_3 usage in the same program as heap\_1, heap\_2, and heap\_3 all define the same functions (pvPortMalloc() and pvPortFree() ), just with different implementations.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [June 13, 2011, 7:33am UTC](https://forums.freertos.org/t/thoughts-on-memory-management/85/3 "2011-06-13T07:33:23Z")

</div>

**[anguel78](https://sourceforge.net/u/anguel78/)** wrote on [Monday, June 13, 2011](https://sourceforge.net/p/freertos/discussion/382005/thread/03704314/#cf10):

> I believe the increase in kernel code size for using heap\_3.c is due to the inclusion of malloc/free in the code

That was what I also thought but was somehow irritated by the description on [FreeRTOS.org](http://FreeRTOS.org).

> if you are already including it for other purposes, than using heap3 likely takes LESS space than heap\_1/2.c since heap\_3.c is itself very simple. Having the kernel use heap\_3.c also adds a bit of efficiency to memory usage, as you don’t lose the part of the heap\_1/2 space not used from the rest of the program.

You are right, heap\_3.c has the advantage that no RAM is wasted and should not give any penalty as long as one does not need to delete tasks, etc.

> Also note, you can NOT mix heap\_1 and heap\_3 usage in the same program as heap\_1, heap\_2, and heap\_3 all define the same functions (pvPortMalloc() and pvPortFree() ), just with different implementations.

That’s right, one would need to use other names.&nbsp; But as mentioned above this is only interesting if only a single task (e.g. gatekeeper) is using malloc() and free(). This way one could probably do without disabling the scheduler when malloc() or free() are called.