6 ms·
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 st
by papaf 6y ago
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.
- deleted 6y ago[deleted]
- orf 6y agoYou can change the global allocator in any rust project. You can write your own easy enough, or use one like jemalloc
- bauerd 6y agoThink with LD_PRELOAD it is always possible to override the allocator?
- dan-robertson 6y agoOnly if it is dynamically linked
- jfkebwjsbx 6y agoThat wouldn’t help. The point is to use local allocators which have extra information about the data structures and usage of the memory. This is routinely done in medium to large C++ programs for different reasons (performance, debuggability...).
- francasso 6y agoI don't get this. Usually I either don't care about how stuff is allocated, or when I care I want to be specific about what allocator should be used where. In the second situation just setting a global allocator wouldn't cut it most of the time, I would want support for customization when I instantiate a data structure.
- josephg 6y agoSure; but when you’re using arenas and things like that you usually you will want different objects allocated into different pools (or with different lifetime properties). Rust only lets you pick one allocator for the entire process, so you can’t specify “all the children of this data structure go in arena A, and this other allocation goes into a traditional heap”. 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.
- steveklabnik 6y agoNot in an abstract way, but you can do this. The compiler has (had? It’s been a while) two different major arenas, in my understanding. There’s just no non-global allocator trait yet, so it’s not easy to abstract over.
- andrepd 6y ago>everything that allocates takes the allocator as a parameter This is also the C++ approach
- afiori 6y agoAs someone that is interested in the topic and in Zig's "provide your own allocator" approach I have a question: would it be possible to make an allocator wrapper that moves values to be deallocated to a different thread? 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).
- steveklabnik 6y ago
- pjmlp 6y agoIn C++/WinRT the same approach is taken, because you cannot just use a memory pool for COM.
- vvanders 6y agoYou can also use the typed-arena crate[0] or roll your own if you're feeling like cracking open unsafe. [0] https://crates.io/crates/typed-arena https://crates.io/crates/typed-arena
- all-fakes 6y agoTyped-arena is a bit limited, because all the allocated values must be of the same type. bumpalo[0] removes that restriction, but it also doesn't run destructors, which can lead to memory and other resource leaks. Another worry I have with bumpalo is that I don't think it's been reviewed thoroughly for unsoundness. Still, bumpalo has been used to great effect in dodrio[1], a React-like library for Rust with really good performance. [0]: https://crates.io/crates/bumpalo https://crates.io/crates/bumpalo [1]: https://github.com/fitzgen/dodrio https://github.com/fitzgen/dodrio
- CoolGuySteve 6y agoEven just keeping a free list and deallocating it’s elements at an idle time is probably cheaper and faster than spawning a thread.
- estebank 6y agoIn Rust you could just call `mem::forget` on whatever heavy thing that you're no longer using is before it would get dropped, but then the programmer is effectively responsible for that memory leak not becoming a problematic leak during refactors. 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.
- mcguire 6y agoIsn't that a problem for the RAII approach?
- kd5bjo 6y ago> 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.
- rcxdude 6y agoThere's also no guarantee the object won't be moved elsewhere, including into a context which never gets freed (for example, you can construct mem::forget using entirely safe code by forming a cycle of reference-counted boxes). That said, Rust has support for such a concept through the Pin trait (which essentially guarantees an object will not get moved until it is 'Unpinned').
- projektfu 6y agoYeah, I like Apple’s (Next’s) approach of pool allocation for each run through the event loop. Defer dealloc, drop pool at the end.
- saurik 6y agoApple's pools are for helping manage reference counts of returned objects (via autorelease) but aren't doing pool allocation (as any of those objects could escape, so you can't do the fast thing of just deallocating the pool). The normal memory allocator is used while in the scope of an autorelease pool.
- projektfu 6y agoTrue, I was thinking the same after I posted. Maybe I’m thinking more of Apache’s approach and how it gets some of the benefits of a fork-per-request server without the overhead.
- andrekandre 6y agoright, so if you do @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?
- mcguire 6y agoUnless your destructors do more than deallocation, in which case you will leak whatever other resource you're managing.
- MaxBarraclough 6y agoA pool can invoke destructors when it is cleared. Might take a bit of overhead (if the pool is to support arbitrary classes), but you could retain the fast pointer-bump allocation.
- wongarsu 6y agoIn a toy raytracer I once wrote in C++, switching from malloc to custom memory pools for small fixed-size objects was a big performance boost. Making free() a noop was another big performance boost, both for deallocation and allocation. Turns out sequentially handing out memory from a big chunk of memory is much easier than keeping track of and reusing empty slots, and it keeps sequentially allocated objects in sequential memory locations.
- folmar 6y agojemalloc is the answer to the question you did not ask
- jomohke 6y agoYou can easily use a custom global allocator in Rust: #[global_allocator] static GLOBAL: MyAllocator = MyAllocator;