Allocator Concept

[Ichthyostega]

As Lumiera Architect,
I want a coherent scheme to be established,
for all parts of the application reliant on custom memory management.

Background

Generally speaking, the Heap Allocator was significantly improved in terms of performance and is adequate for most occasional allocation demands. However, there are some crucial subsystems, which need to maintain a well defined usage scheme for memory and thus will have to rely on some custom allocation scheme. Notably this includes the Builder, and the active components of the Render Engine.

The C++ standard defines a framework for custom allocators, which is in constant flux and unfortunately limited by historically relevant concerns. This framework must be taken into account, for the obvious reason to allow for STL Containers to be integrated in Lumiera's coherent memory management scheme. This standard defines a baseline, but is not well suited to serve as a common anchor or framework for memory management, since it is too much flexible and low-level and suffers from alignment to legacy concerns.

Taking current architectural understanding into account, a scheme for memory allocation and object fabrication should observe the following guidelines

• Separate the object lifecycle management from the memory allocation
• Memory Allocators should be composable building blocks.
• The application framework should rely on a Factory Concept rather than depending on explicitly given interfaces.
• Specific front-end handles should be provided on top of the Factory to express dedicated usage protocols
• Adapters towards the C++ standard allocator should be provided

[Ichthyostega]

Attach to parent #836 (preliminary solution for critical allocations).

[Ichthyostega]

Attach to parent #1430 (Render-buffer pools).