5 ms·
What’s stopping Apple switching its default allocator?
by lukeh 5y ago
What’s stopping Apple switching its default allocator?
- dwaite 5y agoI can't speak to Apple's reasons specifically, but usually it comes down to: 1. Degenerate cases with new allocator designs, e.g. being better for some workloads and not others 2. Bug-for-bug compatibility - applications which break due to dependencies on undocumented behavior or the old allocator memory structures. 3. Boundary conflicts - systems where an allocator change would mean allocation and free are hitting different implementations across module boundaries, as one module allocates memory for another to consume. Some systems and programming languages are more vulnerable to this sort of issue.
- vlovich123 5y agoA fourth one would be debugging support. They have a bunch of stuff in there (perhaps dated these days) to auto scribble on malloc/free, allocate guard pages etc. They probably could/should look into integrating a more modern allocator (mimalloc, jemalloc) and falling back to the old one when those features are needed (assuming they can’t bring them forward).
- pcwalton 5y agoMallocScribble is available as "opt.junk" in jemalloc [1]. As for guard pages, tcmalloc has TCMALLOC_PAGE_FENCE [2], and there is an issue [3] in jemalloc. In any case, Apple and others have invested hugely in LLVM AddressSanitizer, so the Electric Fence-like malloc debugging features are considered more of a last resort these days. [1]: http://jemalloc.net/jemalloc.3.html http://jemalloc.net/jemalloc.3.html [2]: https://chromium.googlesource.com/external/gperftools/+/gperftools-2.2.1/src/debugallocation.cc https://chromium.googlesource.com/external/gperftools/+/gper... [3]: https://github.com/jemalloc/jemalloc/issues/1664 https://github.com/jemalloc/jemalloc/issues/1664
- 1over137 5y agoYeah, but ASan requires recompilation. GuardMalloc and MallocScribble apply to your whole process, and so even malloc()s called by system frameworks (ex AppKit) get checked. I've found several OS bugs this way over the years. Maybe internally Apple has ASan builds of the whole OS, but they don't distribute it externally.
- vlovich123 5y agoWhen I worked at Apple they were the first resort as they were usually cheaper to iterate with (no recompilation, lower overhead, etc), but ASAN has only gotten better & was the primary focus. I agree that maybe jemalloc might be a good drop-in replacement, but it just might not be a priority for the libc maintainers. Lots of low hanging fruit can be missed for very long periods of time because you have to pick what to focus on. GWP ASAN from TCMalloc might be the better direction for runtime support for memory corruption from malloc as it gives a lot of ASAN-like protection with an electric fence-like performance profile (& can be turned on/off at runtime).
- lukeh 5y agoI don't think 3. is an issue for Apple, because there is no static libSystem.
- pcwalton 5y agoI doubt there is any particularly compelling reason other than not having yet paid down that piece of technical debt.
- fay59 5y agoThere’s more to measure with allocators than how fast it can pump out memory. You’d probably want to check for memory overhead and heap fragmentation and various security considerations.
- saagarjha 5y agoMy understanding is that Apple really cares about memory footprint, since they ship hundreds of daemons on machines that often don’t have much memory to spare. So IMO their allocator prioritizes that over say throughout, which might annoy app developers but isn’t necessarily a bad compromise. (In places where Apple has different needs, e.g. WebKit, different allocators are used.)