Box and Vec both make very strong guarantees about their behavior that we need to be careful to keep intact, even as we potentially migrate #[global_allocator] from GlobalAlloc to AllocRef.
To be clear, I don't think Box is really an issue. It seems fairly obvious that it should just be a smart pointer wrapper around AllocRef's behavior.
Vec is a more interesting case, because it makes promises to never allocate when mem::size_of::<T>() * capacity() == 0. In a world where [RawVec uses AllocRef's capability to handle zero-sized allocations rather than skipping calling the allocator (as was necessarily done for GlobalAlloc), calling AllocRef::alloc can break the no-allocation promise for zero-sized allocations.
On the other side, there's the question of AllocRef's "mode" parameters. The addition of these parameters is at least partially reliant on the fact that the compiler is capable of/allowed to optimize the different modes to different calls (or outright inline them), making the extra switch parameters free at runtime while cleaning up the combinatoric explosion of API.
In the dynamically linked #[global_allocator] case, however, this is not the case. Every alloc will have to branch on if the layout is zero-sized and if the allocation should be zero-initialized. For the specific case of the global, dynamic allocator, the tradeoffs are different than the case of a static allocator. Perhaps there will be value in keeping a [Global]AllocRef split, so that the dynamically linked case can explode out some of these concerns.
These are not blocking concerns, by any means. These are just areas of concern I haven't seen mentioned yet that should be recorded and actively considered when making further adjustments to the allocator APIs.
BoxandVecboth make very strong guarantees about their behavior that we need to be careful to keep intact, even as we potentially migrate#[global_allocator]fromGlobalAlloctoAllocRef.To be clear, I don't think
Boxis really an issue. It seems fairly obvious that it should just be a smart pointer wrapper aroundAllocRef's behavior.Vecis a more interesting case, because it makes promises to never allocate whenmem::size_of::<T>() * capacity() == 0. In a world where [RawVecusesAllocRef's capability to handle zero-sized allocations rather than skipping calling the allocator (as was necessarily done forGlobalAlloc), callingAllocRef::alloccan break the no-allocation promise for zero-sized allocations.On the other side, there's the question of
AllocRef's "mode" parameters. The addition of these parameters is at least partially reliant on the fact that the compiler is capable of/allowed to optimize the different modes to different calls (or outright inline them), making the extra switch parameters free at runtime while cleaning up the combinatoric explosion of API.In the dynamically linked
#[global_allocator]case, however, this is not the case. Every alloc will have to branch on if the layout is zero-sized and if the allocation should be zero-initialized. For the specific case of the global, dynamic allocator, the tradeoffs are different than the case of a static allocator. Perhaps there will be value in keeping a [Global]AllocRefsplit, so that the dynamically linked case can explode out some of these concerns.These are not blocking concerns, by any means. These are just areas of concern I haven't seen mentioned yet that should be recorded and actively considered when making further adjustments to the allocator APIs.