Static vs Dynamic Memory Allocation
The first prototype of the kernel only allowed for statically allocated stacks. The intention of this was to start with the most stable and simple form of allocation. For a thread to be scheduled it needs a stack but also management structures. These structures are stored in kernel memory and inaccessible to the user. Hence, for every thread, a management structure is allocated in the kernel. The first software prototype could only a hold a given number of management structures. The amount of available structures is another RTOS parameter that a user has to set. To simplify the user interface it was decided to use dynamic allocation instead. The advantages are one less parameter to tune and errors can be caught at system boot. If all threads and IPC objects are created before the kernel is started, out of memory errors will occur during development and not after deployment.
Eventually, Bern RTOS should support both static and dynamic memory allocation. Critical threads could be set up using static allocation only, to guarantee memory at compile time. Threads with dynamic system loads may rely on other allocation methods.
Every process owns an allocator to prevent one thread from taking all memory from the system. On the other hand, this segments the available memory into smaller pieces, which increases the risk of out of memory errors. Overall the safety from process isolation was prioritized. Additionally, selecting an allocator algorithm per process allows for finer customization for a given use case.