3 ms·
Zig's "general purpose allocator" achieves use-after-free protection by quarantining memory pages forever: i.e. it never reuses heap addresses. This is unsuitab
by pcwalton 5y ago
Zig's "general purpose allocator" achieves use-after-free protection by quarantining memory pages forever: i.e. it never reuses heap addresses. This is unsuitable for production because keeping even a single 16 byte allocation alive on a 4kB page will leak the whole page.
If it were possible to solve use-after-free this way, Microsoft/Apple/Google would have done it long ago for C++.
- flohofwoe 5y agoThis allocation strategy encourages to keep allocation frequency low, which is always a good thing ;) But more seriously, I guess the general-purpose-allocator is mainly useful for catching memory corruption issues during development, despite the name.
- pcwalton 5y agoIf it's designed to be a development tool, then Address Sanitizer for C/C++/Rust does everything that Zig's general purpose allocator does and more. If you follow the strategy behind Zig's "general purpose allocator" to its logical conclusion, you get Google's HWASAN for C++ [1]. It is much more advanced than an allocator that simply quarantines memory forever and uses probabilistic checking to mitigate the problems of quarantining, trading soundness for performance. [1]: https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html https://clang.llvm.org/docs/HardwareAssistedAddressSanitizer...
- smaddox 5y agoI think that's the debug allocator, but I don't know if that's even implemented yet.