Heap considerations
The heap contains dynamic data allocated by use of the C function malloc (or a corresponding function) or the C++ operator new.
If your application uses dynamic memory allocation, you should be familiar with:
The use of basic, advanced, and no-free heap memory allocation
Linker sections used for the heap
Allocating the heap size, see Setting up heap memory.
Heap memory handlers
The system library contains three separate heap memory handlers—the basic, the advanced, and the no-free heap handler.
You can use a linker option to explicitly specify which handler you want to use:
The basic heap (
‑‑basic_heap) is a simple heap allocator, suitable for use in applications that do not use the heap very much. In particular, it can be used in applications that only allocate heap memory and never free it. The basic heap is not particularly speedy, and using it in applications that repeatedly free memory is quite likely to lead to unneeded fragmentation of the heap. The code for the basic heap is significantly smaller than that for the advanced heap. See ‑‑basic_heap.The advanced heap (
‑‑advanced_heap) provides efficient memory management for applications that use the heap extensively. In particular, applications that repeatedly allocate and free memory will likely get less overhead in both space and time. The code for the advanced heap is significantly larger than that for the basic heap. See ‑‑advanced_heap. For information about the definition, see iar_dlmalloc.h.The no-free heap (
‑‑no_free_heap) is the smallest possible heap implementation. This heap does not supportfreeorrealloc. See ‑‑no_free_heap.
If no heap option has been specified, the linker automatically chooses a heap handler:
If there are calls to heap memory allocation routines in your application, but no calls to heap deallocation routines, the linker automatically chooses the no-free heap.
If there are calls to heap memory allocation routines in your application, the linker automatically chooses the advanced heap if the majority of the modules are optimized for speed (Medium, High Balanced, or High Speed).
If there are calls to heap memory allocation routines in, for example, the library, or if the majority of the application modules use optimization level None or are optimized for size (Low or High Size), the linker automatically chooses the basic heap.
Note
If no heap has been specified explicitly, a small piece of trampoline code (heaptramp0.o) will be included in the output to select the heap at runtime, making the binary file insignificantly larger.
The optimization goal used for selecting a heap handler is not always available to the linker—particularly not in object files that were not compiled with an IAR compiler. Such modules are ignored for the decision.
Note
If your product has a size-limited license, the basic heap is automatically chosen.
Heap size and standard I/O
Tip
If you excluded FILE descriptors from the DLIB runtime environment, as in the Normal configuration, there are no input and output buffers at all. Otherwise, as in the Full configuration, be aware that the size of the input and output buffers is set to 512 bytes in the stdio library header file. If the heap is too small, I/O will not be buffered, which is considerably slower than when I/O is buffered. If you execute the application using the simulator driver of the IAR C-SPY® Debugger, you are not likely to notice the speed penalty, but it is quite noticeable when the application runs on an Arm core. If you use the standard I/O library, you should set the heap size to a value which accommodates the needs of the standard I/O buffer.
Heap alignment
In 32-bit mode, the heap is aligned to an 8-byte aligned address.
In 64-bit mode, the heap is aligned to a 16-byte aligned address.
For more information about aligning the heap, see Setting up heap memory.