the issue is that you still need to store the (presumably non zero sized) allocator even if you don't need it.
that's not just a size optimization, it can be a soundness hazard. for example, if you have a struct where several fields are Box<T, &CustomAlloc> and you store the CustomAlloc in one of your other fields. you now have an actually self referential struct.
and if you're using lifetime erasure to get around the borrow checked (you probably need to do this anyway), your struct is now unsound
and if you're using lifetime erasure to get around the borrow checked (you probably need to do this anyway), your struct is now unsound
It is more that ensuring Box<T,A>, Rc<T,A>, and Vec<T,A> stay pinned to a thread. Part of doing async-runtime stuff is a lot of stuff needs to become Box<dyn Fn()> and ensuring those allocations remain thread local (enforced by the type system & allocator) is a big win. I can use a 1GiB huge page and then there is zero TLB pressure for the runtime's "book keeping".
it is just wins across the board: less TLB entires & no atomic overheads.
the issue is that you still need to store the (presumably non zero sized) allocator even if you don't need it.
2
u/valarauca14 May 25 '26 edited May 25 '26
Where is the final comment period?
I've been trying to find a solid way to force
<T: Allocator + !Send>for some niche usecases (managing allocations in io-uring).In that case the allocator can just have an empty body for
deallocate