> move all memory management into centralized systems (like rendering, physics, animation, …), with the systems being the sole owner of their memory allocations
> group items of the same type into arrays, and treat the array base pointer as system-private
> when creating an item, only return an ‘index-handle’ to the outside world, not a pointer to the item
> in the index-handles, only use as many bits as needed for the array index, and use the remaining bits
> for additional memory safety checks
only convert a handle to a pointer when absolutely needed, and don’t store the pointer anywhere
There's two separate ideas here, in my mind, and while they play nicely together, they're worth keeping separate. The first one-and-a-half points ("move all memory management" and "group items") are the key to achieving the performance improvements described and desired in the post, and are achievable while still using traditional pointer management through the use of e.g. arena allocators.
The remainder ("treat the array base pointer" on) is about providing a level of indirection that is /enabled/ by the first part, with potential advantages in safety. This indirection also enables a relocation feature -- but that's sort of a third point, independent from everything else.
There's also a head nod to using extra bits in the handle indexes to support even more memory safety features, e.g. handle provenance... but on modern 64-bit architectures, there's quite enough space in a pointer to do that, so I don't think this particular sub-feature argues for indexes.
I guess what I'm saying is that while I strongly agree with this post, and have used these two patterns many times, in my mind they /are/ two separate patterns -- and I've used arena allocation without index handles at least as many times, when that trade-off makes more sense.
> group items of the same type into arrays, and treat the array base pointer as system-private
> when creating an item, only return an ‘index-handle’ to the outside world, not a pointer to the item
> in the index-handles, only use as many bits as needed for the array index, and use the remaining bits
> for additional memory safety checks only convert a handle to a pointer when absolutely needed, and don’t store the pointer anywhere
There's two separate ideas here, in my mind, and while they play nicely together, they're worth keeping separate. The first one-and-a-half points ("move all memory management" and "group items") are the key to achieving the performance improvements described and desired in the post, and are achievable while still using traditional pointer management through the use of e.g. arena allocators.
The remainder ("treat the array base pointer" on) is about providing a level of indirection that is /enabled/ by the first part, with potential advantages in safety. This indirection also enables a relocation feature -- but that's sort of a third point, independent from everything else.
There's also a head nod to using extra bits in the handle indexes to support even more memory safety features, e.g. handle provenance... but on modern 64-bit architectures, there's quite enough space in a pointer to do that, so I don't think this particular sub-feature argues for indexes.
I guess what I'm saying is that while I strongly agree with this post, and have used these two patterns many times, in my mind they /are/ two separate patterns -- and I've used arena allocation without index handles at least as many times, when that trade-off makes more sense.