4 ms·
Like I said, if your allocator is actually the system allocator then yes maybe you're right. If instead you're doing something like using an arena allocator the
by secondcoming 3y ago
Like I said, if your allocator is actually the system allocator then yes maybe you're right. If instead you're doing something like using an arena allocator then OOM isn't a huge deal, because all you've done is exhaust a fixed buffer rather than system RAM; totally recoverable. There are huge performance gains to be had with using custom allocators where appropriate.
- kibwen 3y agoSure, and you can do that with Rust today. There's nothing stopping you from writing a custom data structure with its own custom allocator. The "abort on OOM" policy is not a property of the language, it's a property of certain collections in libstd that use the global allocator.
- eska 3y agoI think the point here is that users would like to use Vec, HashMap etc using that arena allocator and handle OOM manually instead of having to write their own collection types.
- temac 3y agoIf that's the first time you touch the last bits of your private arena, you can trigger the OOM killer.
- dureuill 3y agoTrue, but also worse than that: if an unrelated application starts consuming slightly more memory it can trigger an oom kill of your application