custom class allocator delegating to mpool

[Ichthyostega]

build a simple per-class custom allocator, which in turn delegates to the mpool service in the Vault-Layer. This is nothing fancy, just a correct implementation of operator new and operator delete, together with a unit test to prove its effectiveness.

[Christian Thäter]

Replying to ichthyo:

build a simple per-class custom allocator, which in turn delegates to the mpool service in the Vault-Layer. This is nothing fancy, just a correct implementation of operator new and operator delete, together with a unit test to prove its effectiveness.

mpool is in lib, as it is stateless, you create your own mpools for some purpose. These may (should) hook into the resourcecollector. The resourcecollector is currently in lib too, despite it has some global state, maybe we shall move it to common or vault.

[Christian Thäter]

Replying to ct:

Replying to ichthyo:

build a simple per-class custom allocator, which in turn delegates to the mpool service in the Vault-Layer.

mpool is in lib, as it is stateless, you create your own mpools for some purpose. These may (should) hook into the resourcecollector. The resourcecollector is currently in lib too, despite it has some global state, maybe we shall move it to common or vault.

the resource collector will move to the vault and augment the mpool proactively, nothing to care about for mpool users see ticket #521

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin

[Ichthyostega]

this whole undertaking is ill-guided

For this kind of tasks, we should start from a requirement — and not start with implementing a technology (pooling allocation) and then look for usages.

In my defence, I wasn't aware of the specific strength (and weaknesses) of the C++ language, and also the language itself has changed significantly in the meantime. Generally speaking, memory allocation is not a matter of "some classes", it is a question of architecture rather. We should think in types, and some types have reference semantics — and these typically belong to or are related to some service. A service in turn has a lifecycle and a typical usage trend — and this is the place where you'd consider how to approach memory requirements.

If we fail to put memory usage properly into perspective, we'd end up implementing a »custom general purpose allocator« (which is an oxymoron). In any larger application, there will be a lot of tiny details that do not fit into any larger scheme. In such cases, it is best to use the standard heap allocator, which usually performs quite well in contemporary C++ runtime systems, and was optimised for being general purpose