I wonder how to mix multiple allocators in a safe way. Say an arena allocator and the default one. How to prevent the non-arena object points to the arena one? (The problem is: the arena could get wiped, so this pointer would be invalid.) The post is about Rust, so I was hoping this is adressed...
I'm working on my own programming language and want to support multiple allocators. Usually languages just support one OR the other, safely.
I would imagine the normal lifetime arrangements in Rust would prevent this, the same way it prevents nesting a shorter lived pointer inside a longer lived struct when they're all from the same allocator.
In general in Rust, lifetimes enforce that references to a thing do not outlive the thing itself.
Even in unsafe code, it is possible to tie the lifetime of the allocations to the lifetime of the thing handing out the allocations, meaning that if you ever attempt to "escape" the scope, e.g. storing a shorter lifetime allocation in a longer lifetime allocation, that outer item can now only live as long as the shorter lifetime (even though it derives from the longer lifetime allocator). Any violation of this becomes a compile time error.
For example, within a function, you can have a Vec of references to local items, and although the Vec is an allocation, and COULD live forever/as long as necessary (allocations have 'static lifetime), that Vec MUST be dropped at or before when the references it contains would become invalid.
> We design a type system that tracks the underlying storage mode of values, and when a function returns a stack-allocated value, we just don’t pop the stack Instead, the stack frame is de-allocated together with a parent the next time a heap-allocated value or primitive is returned.
> Our evaluation shows that this execution model reduces heap and GC pressure and recovers spatial locality of programs improving execution time between 10% and 25% with respect to standard execution.
Wouldn't that be expensive to use with FFI, or call the OS functions? What about interrupt handling? Didn't Go went through a similar phase with spaghetti stack, only to revert back to standard one.
Then it'll be tricky to do yet another "stack" walker to obtain performance metrics (eBPF, or say on Windows through standard ETW mechanisms)
I'm working on my own programming language and want to support multiple allocators. Usually languages just support one OR the other, safely.