Working with Multiple Heaps

[aclysma]

(Credit to @jaynus for bringing this up!)

In game development, it’s common practice to have multiple heaps.

Common Usecases:

• Tracking memory usage from different systems.
  • An allocator may be tuned for a specific system's allocation pattern
  • In some cases, the heap is intentionally small and failing to allocate is expected to be non-fatal. For example, dropping a UDP packet if you can't allocate memory to process it.
• Some hardware supports “debug” memory not available on retail
• Some devices have multiple regions of memory with different performance characteristics.

As far as I can tell, Rust's support for custom allocation is incomplete, but being worked on. There is a working group to try to address this: (https://github.com/rust-lang/wg-allocators/issues). It looks to me like there is general consensus around what to do, it just isn't done yet. However, much of it is available in nightly.

There is an open issue to add an allocator type param for Box, Rc, String, Vec, and other collections/pointer-like types (rust-lang/wg-allocators#7). For now it looks like it is blocked by rust-lang/wg-allocators#2)

I can think of two temporary workarounds for having multiple heaps, but there may be others:

• It looks like someone could reimplement collections on top of RawVec, which takes an allocator, but this is not a stabilized API so requires nightly. Porting the most commonly used types from std probably wouldn't be too difficult. But other types like Box, Rc would also need to be implemented.
• It would also be possible to call a function on the global allocator to set the current "default" heap, and then create the Box/Vec/Whatever. While doing this directly is quite dangerous, it would be possible to wrap types like Box/Vec that do this on construction/destruction. (However, it must be said plenty of shipped games have code that manually pushes/pops the current allocator!) I believe setting a custom global allocator is available in 1.36 for no_std and 1.28 for std, so this would be feasible without nightly.

I suspect that the work needed to solve most needs for game development is already queued up, and if all of that work were completed and stabilized, I think Rust would be in good shape here.

[Wodann]

Also, see #60.