Hacker News Reader

Comment by lukeh | Hacker News Reader

What’s stopping Apple switching its default allocator?

I 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.

A 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).

MallocScribble 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

[2]: https://chromium.googlesource.com/external/gperftools/+/gper...

[3]: https://github.com/jemalloc/jemalloc/issues/1664

Yeah, 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.

Valgrind works OK on macOS, right?

According to release notes, it supports 10.12 (with preliminary support for 10.13). That's several releases behind (10.14, 10.15, 11, 12).

it hasn't for years afaik

Homebrew won't even install valgrind anymore.

Security-critical components like the kernel and WebKit have ASan variants, that’s for sure. But they also use custom allocators.

When 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).

Apple has a whole set of heap debugging tools that they use internally and are quite useful even as a third party developer, and I’m sure they rely on having certain heap metadata around so they can reconstruct a memory graph after the fact. Take a look at heap(1) and leaks(1) to see what they offer.

I don't think 3. is an issue for Apple, because there is no static libSystem.

My 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.)

There’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.

I doubt there is any particularly compelling reason other than not having yet paid down that piece of technical debt.

Reply on news.ycombinator.com