this looks awesome, great to see the ‘size-passed-into-free’.
has anyone considered the option of a hints word passed to the
lowest level of the allocator, e.g:-
- use hints r.e. threading - thread-local vs inter-thread use
- use hints r.e. lifetimes - frequent/short vs infrequent/long, grouping ('these things will be alloced/freed together)
- use hints r.e. device use, GPU-able vs CPU only (see modern gpu unified memory)
- other possible use cases on NUMA systems (embedded machines with scratchpads? supercomputers?)
maybe something like a general purpose 32bit hints field, which can’t change the semantics , but which can guide choices that could have benefits in these scenarios. the hints could be devised such that passing ‘0’ is a safe assumption for most programs.
in particular the use cases I had in the past involved a big dividing line between allocations r.e. lifetimes - persisting for multiple frames, level load, level load temporaries, intra-frame temporaries, texture-streaming buffer. I’m sure people in other domains will have had different requirements and issues.
IMO allocators per type as seen in C++ can be quite useful, e.g. in the above case you have ‘entities’ , ‘vertex data for the gpu’, ‘texture objects’ which are all distinct types with distinct allocation behaviour ,but you might be able to get better control than C++'s system allows.
( I know that custom buffers owning the objects is another way to control things , arguably better… and more useable at a high level today with ‘emplace back’; again perhaps that could back onto the same underlying hint word passed to the lowest level allocator )