Heap/Slab allocators: separate mechanism from API

[nfeske]

The Heap and Slab allocators implement the Allocator interface by operating on a Ram_allocator and a local Region_map (the component's virtual memory. Since all these interfaces are fixed, they are not always a perfect fit:

• The virtual address space of the core component is not a region map. To nevertheless use Heap and Slab within core, a pseudo region-map implementation is needed, which imposes the use of dataspaces onto core, which in turn adds complexity to no benefit.

• The new operator requires exception support to reflect allocation errors. The Allocator interface is thereby "infected" by the C++ exception mechanism. To move away from C++ exceptions, we need to abolish the use of new (Allocator &). However, without new there is no good reason for the Allocator interface to exist in the first place.

• Allocator::alloc takes the number of bytes as argument. This makes no sense for the slab. The invariant that the allocation size fits a slab entry cannot be ensured at compile time.

These are good reasons to revise the Heap and Slab to model different allocation scenarios (core/outside core, constrained/unconstrained) via exception-free interfaces. So avoid duplicating the allocator's implementation for each scenario, the mechanism for the allocators (using one specific type each) must be separated by their (templated) API (allowing for different types of heaps and slabs).