Bryan B

I'm supportive and I think it fits with the overall architecture and direction of the project (DXCore backend). @bjjones Can I assign you to dig into this?

Sounds like it. This issue wants to amortize dynamic allocations from the C++ runtime, created by GPGMM itself. The `SlabMemoryAllocator` targets GPU device memory and cannot malloc/free from C++ runtime...

When you say "use std::pmr", would we literally just replace either std:: containers and non-std:: containers, no matter how they're used? Also, you say (1) is important (I agree) but...

What happens if nodes are removed/inserted in the middle somewhere, are we just going to keep re-sorting? ResidencyManager doesn't need random insertion across the whole list, only by set. SlabMemoryAllocator...

The key part was "across the whole list". You could just remove any heap within the set by swapping the last heap with the removed - requires no reallocation. Reallocation...

You can move any heap within the same set and the LRU would not lose order. If you move a heap anywhere from the LRU, the LRU needs to maintain...

Unless your free-list maintains order, the randomly de-allocated nodes will not be stored contiguously. Not unless the data structure allocating them is also contiguous (ex. array, vector, dequeue) and not...

I don't think we can modify/override buildtools because then `third_party/gpgmm` (or non-standalone) would not build, unless DEPS gets rolled with your change (and build_override is modified in parents, if needed)....

You can specify a custom allocator with non-`std::pmr` STL containers too, but it would be statically typed (replaces default `std::allocator`). There would just be no dynamic dispatch or common allocator...

@bjjones, this one would be a good follow-up work item.