Embedded Systems – Drawbacks of Allocating a Huge Amount of Stack for a Single Array

There are two different memory limits. The virtual memory limit and the physical memory limit.

Virtual Memory

The virtual memory is limited by size and layout of address space available. Usually at the very beginning is the executable code and static data and past that grows the heap, while at the end is area reserved by kernel, before it the shared libraries and stack (which on most platforms grows down). That gives heap and stack free space to grow, the other areas being known at process startup and fixed.

The free virtual memory is not initially marked as usable, but is marked such during allocation. While heap can grow to all available memory, most systems don't auto-grow stacks. IIRC default limit for stack is 8MiB on Linux and 1MiB on Windows and can be changed on both systems. The virtual memory also contains any memory-mapped files and hardware.

One reason why stack can't be auto-grown (arbitrarily) is that multi-threaded programs need separate stack for each thread, so they would eventually get in each other's way.

On 32-bit platforms the total amount of virtual memory is 4GiB, both Linux and Windows normally reserving last 1GiB for kernel, giving you at most 3GiB of address space. There is a special version of Linux that does not reserve anything giving you full 4GiB. It is useful for the rare case of large databases where the last 1GiB saves the day, but for regular use it is slightly slower due to the additional page table reloads.

On 64-bit platforms the virtual memory is 64EiB and you don't have to think about it.

Physical Memory

Physical memory is usually only allocated by the operating system when the process needs to access it. How much physical memory a process is using is very fuzzy number, because some memory is shared between processes (the code, shared libraries and any other mapped files), data from files are loaded into memory on demand and discarded when there is memory shortage and "anonymous" memory (the one not backed by files) may be swapped.

On Linux what happens when you run out of physical memory depends on the vm.overcommit_memory system setting. The default is to overcommit. When you ask the system to allocate memory, it gives some to you, but only allocates the virtual memory. When you actually access the memory, it will try to get some physical memory to use, discarding data that can be reread or swapping things out as necessary. If it finds it can't free up anything, it will simply remove the process from existence (there is no way to react, because that reaction could require more memory and that would lead to endless loop).

This is how processes die on Android (which is also Linux). The logic was improved with logic which process to remove from existence based on what the process is doing and how old it is. Than android processes simply stop doing anything, but sit in the background and the "out of memory killer" will kill them when it needs memory for new ones.

Microcontroller programs consist of a number of tasks. Let's say you wanted to make a computer-controlled telescope mount. The tasks would be:

• Retrieve a new byte of input from the USB serial buffer.
• Check if we've received a complete command.
• If so, execute that command.
• Read the sensors for the current telescope position.
• Set the proper output to control the next step of the motors.

This is a fairly typical set of tasks for something you would use a microcontroller for, and are pretty easy to manage with an infinite loop, like:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

If you keep adding and adding features, you eventually start coming across common problems you want to create abstractions for, like:

• Your buffer is overflowing, so you want to make sure that task can interrupt other tasks before it overflows.
• You want to save battery by sleeping when nothing is needed.
• You want to make sure all tasks get a fair shot. If readSensors takes too long, you want to be able to interrupt it and come back to it later.
• You want to be able to just reset one task without affecting others.
• You want a memory leak or other bug in one task to not take out the other tasks.
• You want to be able to give different tasks different priorities.
• You want to be able to sandbox an untrusted task.
• You want to be able to execute tasks at different rates. Perhaps your sensors can only be read 10 times per second, but you want to execute a motor step 100 times per second.

One or two of these items can be handled manually relatively easily. If you have enough of these kinds of problems frequently enough that you start generalizing them into libraries, you've basically reinvented an RTOS. If your program's task management is complex enough, even if you don't use an off-the-shelf RTOS, you will eventually end up reinventing one poorly.

However, in my experience, the line where you want an RTOS is very close to the line where you want a microprocessor instead of a microcontroller. If you anticipate your firmware getting that complex, it's usually better to go the microprocessor route from the beginning.