This deallocation trick is neat but in C and C++ you could use a memory pool to do this.
In theory, you could also use a memory pool in Rust but I think the standard library uses malloc without some way of overriding this behaviour.
In theory, you could also use a memory pool in Rust but I think the standard library uses malloc without some way of overriding this behaviour.
Still, bumpalo has been used to great effect in dodrio[1], a React-like library for Rust with really good performance.
This is routinely done in medium to large C++ programs for different reasons (performance, debuggability...).
It’s more awkward, but I much prefer Zig’s approach here where everything that allocates takes an allocator as a parameter. Usually the allocator is specified at compile time - in which case zig can generate identical code to the rust compiler. But when you want the flexibility, it’s there.
Aside from compilers, this is heavily used in video games where there’s often a lot of objects that get allocated per frame, and can be discarded all together. And in that case rust’s lifetime tracking would be a huge asset. The dovecot email server (C) also makes superb use of a mix of memory containers for different tasks. Given how messy email parsing is, dovecot is an absolute pleasure to read.
This is also the C++ approach
As far as I know it would require both Rust's borrowing semantics and Zig's architectural choice.
From purely my own fan-boy perspective Zig approach is something that I would have really liked for Rust to adopt (I have no idea of which one came first chronologically).
Edit: this will also break any code that relies on Drop being called for clean up, but that is already a "suspect"/incorrect pattern because there are no assurances that it will ever run.
Yes and no. Whenever control leaves a code block, Rust automatically calls the drop() method of all values still owned by that block. There is no guarantee that control will exit every block (cf. Turing), but a moderately exceptional circumstance needs to occur for this not to happen, like an infinite loop.
@autoreleasePool { [[[SomeObject alloc] init] autorelease]; }//someobject is release after exiting this scope
//inside main runloop, not inside @autorelease{} [[[AnotherObject alloc] init] autorelease];
//AnotherObject will be release at end of main runloop
[[NotAutoreleased alloc] init]; //will leak past runloop iteration
is that understanding correct?
TR::Region is the slab allocator used by the JIT in OpenJ9/OMR. The linked commit adds functionality for calling destructors of arbitrary types allocated in the Region.
#[global_allocator]
static GLOBAL: MyAllocator = MyAllocator;