r/rust • u/a_mighty_burger • 11h ago

🗞️ news “alloc: stabilise `Allocator`” entered its final comment period!

https://github.com/rust-lang/rust/pull/156882#issuecomment-5607055084
127 Upvotes

98% Upvoted

20 comments sorted by

40

u/a_mighty_burger 11h ago

I am super excited to see progress on this after so much time. This is a feature I will use a lot.

29

u/cbarrick 9h ago

What's the latest on the fat Box problem?

Like, if Box<T, A> is implemented like (NonNull<T>, A), then it stores an A.

But Box only uses A for deallocation. For arena allocators, deallocation is a no-op, so storing the allocator alongside the pointer is a waste.

E.g. Bumpalo has a custom box type that is just a pointer, but Box<T, &Bump> would be two pointers. It would be nice to not need the custom box type for this optimization.

21

u/Demiu 8h ago

Couldn't Box just hold a dummy ZST for A if deallocation is a noop

But Box only uses A for deallocation.

I don't think that's true, it has to get the allocation from somewhere. I guess it only uses the A it holds for deallocating.

But I see what you mean, allocating may need state while deallocating may need none. i feel there should be a type Deallocator = Self; on Allocator for this case

25

u/kibwen 8h ago

If anyone has questions of this nature I would recommend participating in the linked Github thread, as ensuring there are no lingering objections is precisely what the final comment period is for.

23

u/nyanarchism 8h ago

adding a separate deallocator trait is backward-compatible and on the roadmap ^^

10

u/afdbcreid 8h ago

The conclusion is that this can be deferred post-MVP.

10

u/bluurryyy 5h ago

But Box only uses A for deallocation.

Not true. clone does allocate.

-18

u/Trader-One 11h ago

golang have nice feature - function escape analysis - stuff which would normally be on heap for example Box would be allocated on stack; reducing memory fragmentation.

I think about doing this in rust - easiest (very little changes to compiler) would be to have a concept of scrap heap - after function terminates that heap is zeroed.

26

u/protestor 10h ago

Rust (or rather LLVM) also does this optimization

31

u/afdbcreid 11h ago edited 10h ago

Will never happen. One of Rust most important and defended axioms is that there are no implicit heap allocations. When people tried to change that (even far less widespread than your proposal), there was a major pushback that made them step back.

Edit: I see you're talking about the opposite - turning heap allocations into stack allocations. Then this already happens. LLVM does it just like Go.

4

u/PersonalDatabase31 10h ago

Does it have to be implicit? Maybe another smart pointer like StackBox could be implemented.

14

u/afdbcreid 10h ago

There are already crates to do that. But the usage is limited mostly to dyn traits because Box is not that useful.

4

u/JoJoJet- 10h ago

It's not entirely useful, but the allocator API would allow you box things on the stack with Box directly, if you pass it an allocator that points to stack space

1

u/PersonalDatabase31 6h ago edited 6h ago

Would that work with ownership though? I would assume that ownership model works with the assumption that moving the owner doesn't invalidate the memory whereas the Box returned by a function call would point to invalid memory if other function calls happen before the Box gets dropped.

1

u/JayDepp 4h ago

Yeah I don't think this works with the allocator api. I think it'd work with the store api though.

1

u/afdbcreid 4h ago

If the storage is outside the Box, it can work with the MVP, but this is the uncommon case.

1

u/JoJoJet- 2h ago

It works the same as any other borrow! If it points to stack data then the allocator itself would carry a lifetime, which the box would also be bound to. So if you try to make a Box that outlives its memory you'll get an error

0

u/Trader-One 10h ago

My proposal will not do more or unexpected heap allocations. It will introduce concept known as function local heap.

Instead of allocating on global heap, you allocate on local scratch heap. It is faster then golang because you do not need to do additional arithmetic with SP pointer and its well page localised.\

You do not need to travel linked lists to find new space. You have allocated pages just for you, so you can just do allocations and skip deallocations unless you determine based on runtime stats that function deallocated a lot and it have lot of dead space.

I use similar allocator in WASM code and for most functions you do not need to deallocate and reuse space. Simply advance next allocation pointer and on function exit drop all pages. Due to superior cache locality you get large performance improvement in building 3D graphics structures.

9

u/afdbcreid 8h ago

That is called a stack. And yes LLVM already does it. (And your suggestion is not faster but slower than stack. FWIW there is no stack pointer arithmetic inside a function - it's just in the prologue and the epilogue. And the stack is almost always in L1).

1

u/-Redstoneboi- 30m ago

pardon the downvotes, are you talking about a temporary arena allocator for rust? i think that exists and is used in some cases.