Why Heap Allocations is avoided for RTS and Space Applications

Dynamic Memory Allocation often brings Unpredictability

Memory Layout

To motivate the understanding of the avoidance of heap, its best to familiarize or acquit yourself with the Basic memory layout of a a program in execution

Program Code (Text Segment) - Memory containing the compiled code of the program and typically is marked read only to restrict unwarranted access. They are also often placed at the lower part of the memory

Data Segment and BSS Segment - BSS (Block Started by Symbol) segment and the Data segment lies above the Program Code in the memory layout of the program . The BSS and the Data Segment are used for two different purposes

• Data Segment : Stores Initialized Global and Static variables which are initialized with some value at compile time . They contain both the variables which are marked read only through const keyword or the variable which are susceptible to change throughout the program . Thus the Size of the segment depends upon the initialized global and static variables in the program.

static int z = 15 //Could be in function
int y = 15; //declared globally outside function scopes 
        

• BSS Segment: Unlike the Data Segment, the Data Segment stores uninitialized global and static variables which are declared without initialization, Thus the variables are automatically declared with value of zero at runtime. Size of the BSS Segment thus depends on the number of uninitialized variables which are in the program .

static int count //Untialized static variable 
int outside_ //global variable declared outside function scope        

The BSS and Data Segment are separated because of the nature of the values stored in both. The BSS Segment are uninitialized and thus they are initialized with value of zero by program , hence its better for an Operating System to keep it separate for the optimization.. Further Reading about this [Seperation as Two Sections]

The BSS Segment and Data segment necessarily constitutes global allocations or Static Allocations

Stack-Based Allocation - The Stack Based allocations holds one of the prominent position in the memory layout of the program , The stack is typically located near to the top of the memory and grows downwards (from higher memory addresses to lower memory addresses)

The Stack stores the frames each of which represents a function call. The Stack frame contains predominantly the major components namely the return address, any function arguments passed on to the stack and any local variables defined in the function. Any function when called pushes the frame on the stack and when the function is returned, it is popped out of the stack

The Stack Based Allocation gives several advantages which makes it much more safe . These advantages would be applicable when we discuss why heap based allocation should be avoided

1. The Size of the stack frame is determined by the compiler before hand, thus when stack is pushed the compiler know exactly what size of the frame is pushed which ensures the hugely predictable behavior of the program and ensure it is transparent to the programmers
2. The Overhead associated with stack based allocation is minimal because we all need to is just push the stack frame pointer to appropriate location which pushes or pop the frame appropriately
3. The inherent nature of the Stack allocation makes it such that it ensures the memory management leaves no residual and requires minimal manual intervention

Heap Based Allocation - Heap Based Allocation is what allows the program to spread its wings far out in the wild . The Heap Based allocation allows the Dynamic allocation of memory for one or more purposes during runtime. It gives an abundance amount of flexibility to the programmers where the memory size of allocation is not known at compile time (Dynamic DS Structures)

Heap Dynamic allocations happens in the heap segment of one program layout which is just located above the data segments. Typically heap grows upwards (towards higher memory address)

int *arr = new int[10]; // Allocates memory for an array of 10 integers
int *arr = new int[10]; // Allocates memory for an array of 10 integers        

The flexibility of the Dynamic allocations while allows the programmers and developers ton reach the sky, its however is not something which is looked favorably by real time application programmers.

The nature of the heap based allocations makes it really unpredictable and thus unsafe which makes it potentially dangerous for any applications which are critical in functionality

Some of the disadvantages of the heap-based dynamic allocations. These Disadvantages would be applicable for discussion later on

1. Frequent allocations of the memory and de-allocations would result in a scenario where the memory is spread out in a non-contiguous manner. This phenomenon is what we call memory fragmentation. Thus it might result in the scenario where there might be sufficient memory available but since they are scattered in non-regular memory, the system is unable to find a sufficient contiguous block to grant to the program. Most Importantly the heap allocations suffer from the issue of the non-reproducibility, no two instances of a series of heap allocations would result in the same state of the heap which is non-optimal for real-time applications as it tends to make the execution of the program unpredictable
2. Unlike Static and stack-based allocations, dynamic heap allocation has an element of manual intervention which might create problems for critical applications as there is an element of human error when allocating and de allocating from the heap itself. The allocation of memory may be not freed during runtime leading to wastage of that memory segment which remains unavailable for the rest of the program. This is a problem that can magnify quickly if the allocations happen in repetition eventually leading to a much bigger portion of memory eventually at large for the program. We call this as memory leaks which is common occurrence when allocating from heap

int *arr = (int *)malloc(10 * sizeof(int));
// Forgot to call free(arr);
        

1. The Human error is an inherent part of the dynamic allocation which manifests itself in other issues like Dangling Pointer which could happen when the memory although deference is accesses again leading to an undefined behavior leading to an unexpected runtime issues in the program

int *ptr = (int *)malloc(sizeof(int));
free(ptr);
*ptr = 10; // Undefined behavior        

The Demons of the Dynamic Allocations on Space and RTS applications

There might be several pointers above which might be relevant for our discussion

Unpredictability and Overhead - The Significant Issue here lies is the lack of transparency in the program in its runtime with respect to the flow and the allocation of the memory. The Stack and static allocation is safe and predictable for their size is known at compile time. Thus the programmers can reasonable trace the flow of the execution with high predictability

Dynamic allocations is allocated at run time. Hence there is a possibility that some undefined amount of memory might expand and collapse in unknown ways which can be a huge detrimental for the critical applications. The programmers simply cant afford to be okay with this case for it might bring a large no of unintended consequences

There might be a possibility that required memory from the heap is simply not available due to memory fragmentation and otherwise . This will kill the process, eventually leading to some failing of procedure which might be very critical in this .

Non Deterministic Allocation also remains a problem which might prove to be problematic. Dynamic Allocations often requires a significant overhead which requires consultation and to keep track of where the free parts of heap are available. This overhead is something which puts a stress on the hardware which itself do sent have much juice to provide. This directly leads to the issue of the non trivial time in allocation. Stack allocation has a predefined time to allocate memory which we cant say its true for heap allocations which might lead to some variation in time allocations. These differences in time might prove very dangerous for these critical applications namely RTS and Space Applications where even the most trivial amount of time matters

Manual Intervention - The biggest issue here lies in the fact of manual intervention, which often brings in the sense of the human unpredictability that often prove to be problematic as human beings are prone to error . Dangling Pointer and the Memory leak are one of the things we discussed which might lead to severe consequences in the program execution.

The static and stack allocations are safe in these behavior as they are entirely managed by the program execution requires limited manual intervention . Most of all, these stack and static allocations are entirely transparent to the programmers in terms of execution, the time for allocation thus providing a safe and secure tracing of the program flow which isn't the case with dynamic and heap allocation due to an element of human intervention for memory management along with the element of unpredictability it brings to the program flow

Complexity in Certification - Safety Critical Systems in aerospace (DO-178C[2]) often have a huge stringent requirements for the reliability which is headache when heap allocation is involved because its hugely difficult to validate and certify the heap usage and its behavior in the program execution

Thus in short Heap allocation introduces unpredictability, inefficiency, and risks that are difficult to tolerate in space computing ,embedded and other real time applications

References and Other Readings

1. Chien E. and Sz?r P., Blended attacks exploits, vulnerabilities, and buffer overflow techniques in computer viruses, 1, Proceedings of the Virus Bulletin Conference, 2002, New Orleans, La, USA, 72–106.
2. https://en.wikipedia.org/wiki/DO-178C
3. https://medium.com/@kmorpex/understanding-memory-management-in-c-with-stack-and-heap-b79f14569433
4. https://trebledj.me/posts/dynamic-memory-embedded-bad/
5. https://electrical.codidact.com/posts/286121
6. https://stackoverflow.com/questions/1549945/why-would-you-ever-want-to-allocate-memory-on-the-heap-rather-than-the-stack
7. https://www.quora.com/I-ve-read-that-in-critical-cases-dynamic-memory-allocation-is-avoided-What-s-a-good-approach-for-memory-management-in-those-cases-How-does-it-work-when-the-software-needs-to-run-for-a-very-long-time-without