-
Notifications
You must be signed in to change notification settings - Fork 0
Do not use dynamic memory allocation
| Item | Value |
|---|---|
| Guideline Number | 39 |
| Guideline Responsible (Name, Affiliation) | Philippe Millet, Thales |
| Guideline Reviewer (Name, Affiliation) | Habib ul hasan Khan, TUD |
| Guideline Audience (Category) | Application developers |
| Guideline Expertise (Category) | Application developers |
| Guideline Keywords (Category) | application development optimization |
Do not use dynamic memory allocation unless you actually need it.
Dynamic memory allocation means that the amount of memory used by your application varies at run time.
Using dynamic allocation has several drawbacks:
- it is time consuming
- it creates holes in memory
- it can fail in finding the required memory amount
Therefore, the data must be statically allocated. This allows the developer to know at compile-time if the application memory needs can be fulfilled by the hardware platform and does not require time at run-time to find a proper memory location for the data.
Recommended implementation method of the guideline along with a solid motivation for the recommendation
When programming in C, this is what we get when calling the malloc() and free() functions. It is also used in C++ while creating or destroying objects.
Malloc() is used by the application to tell the operating system that a given amount of memory is necessary for the application. When calling the malloc() function, the operating system will scan the memory to find a hole (an empty region) where the requested data size can fit. When calling the free() function, that memory space will be marked as free again and can be selected again when calling the next malloc().
Scanning the memory is time consuming and it is not possible to predict how long it will take for the operating system to find an empty space for the requested data size. Another problem comes after calling malloc() and free() with variable data size holes appears in memory. After several such malloc()/free() sequence the holes become too small to fit any data size and it is not possible to allocate any memory anymore. To overcome this problem, operating systems often implement a "garbage collector" which will compact the memory and remove the holes. The garbage collector is also a time-consuming task which must not be allowed with real-time application.
Embedded systems have much smaller memory that desktop PCs which increases the need to compact the memory.
Another dangerous aspect of the malloc() function is that it returns NULL when it cannot allocate memory. Malloc() results must be checked prior to be used as it will lead to segmentation faults if you try to use a pointer to NULL.
This is also the reason why one should avoid using C++ code on embedded real-time applications.
If dynamic allocation is really necessary, then it must be called at an initialization phase of the application and free() must never be used at run-time, i.e. after initialization.
No dynamic memory allocation is used in the operating system, the libraries and the application at run-time.
The initial code of the medical use case was written on C++. Prior to port it to the embedded targets, we translated the code into C.
The C++ code could compile on the Tegra X2 tool chain, but the performances were very poor. While we translated the code into C, we also made the allocations static and rewrote the filters in C to deal with the static allocated data.
none
TULIPP Guideline Wiki