mirror of
https://review.haiku-os.org/haiku
synced 2025-02-07 22:35:26 +01:00
7132b79eaf
Hoard, the LGPL-licensed locking thread-caching allocator that we have used by default since libroot's introduction, is showing its age. It is a "pseudo-sbrk-based" allocator (it predates our actual sbrk, so instead it uses a single Be area), which has serious limitations: as we cannot ever move the area, we can only resize it "in place", and so once we hit the end of the ~1.5GB reserved part of the address space for the heap, we are usually out of luck if we need more memory. On 32-bit userspace has only 2GB of address space anyway, but on 64-bit where address space is not a resource worth worrying about, this can be a serious problem for applications that want to use a lot of RAM. As more and more large applications get ported to Haiku, the time for a mmap-based allocator has come. For posterity's sake, here are all the possible options there were, and why this one was selected rather than one of them, beginning with the immediate rejects: * nedmalloc. Unmaintained since 2014 and all benchmarks show it underperforming vs. virtually all other allocators. * bmalloc. Significantly worse-performing vs. other options on this list with no apparent advantages. * hoard3. Now GPL only, which is obviously not acceptable for use as a system library. * ptmalloc2. glibc's default allocator; underperforms vs. even most of the above-listeds. And now on to the honorable mentions: * tcmalloc. This is Google's allocator; it's designed for server and other high-performance workloads. As a result, it almost never unmaps memory unless ordered to do so in a very explicit way, which obviously is unacceptable behavior for a general-purpose allocator. * jemalloc. This is FreeBSD and NetBSD's default allocator as well as finding use in Firefox and Rust. It is again designed for performance, with significantly higher memory overhead than other allocators, especially for small heaps; which is of course a problem for us, as we want to retain our light footprint. Finally this brings us to rpmalloc. It's not as well-travelled as tcmalloc or jemalloc, but by benchmarks done by itself [0] and by developers of other allocators [1], it seems to typically hit the "sweet spot" of very good performance with lower (if not the lowest) memory use out of all the other allocators it's tested against; even beating jemalloc in certain benchmarks for speed, too. You can see a description of the allocator's design in its README [2]. [0]: https://github.com/rampantpixels/rpmalloc/blob/master/BENCHMARKS.md [1]: https://github.com/ezrosent/allocators-rs/blob/master/info/elfmalloc-performance.md [2]: https://github.com/rampantpixels/rpmalloc#rpmalloc---rampant-pixels-memory-allocator In general testing thus far on Haiku, it appears to be a consistent 5-10% performance boost (1m28s real -> 1m23s real) when doing the "HaikuDepot compile" benchmark. Memory usage by most apps after a cold boot changed negligibly (launch_daemon: 444K -> 476K, app_server: 15.86MB -> 15.49MB, Tracker: 6.19MB -> 4.49MB.) The only adverse affect I have observed so far is that a certain few WebKit double-frees cause crashes/asserts faster than they did before (e.g. Google Maps crashes after less than a minute instead of a few minutes.) That being said, any new or strange behaviors, please report immediately. Backing out this change should be as easy as reverting the changes to the libroot/posix Jamfile. If nothing else comes up in a few weeks, then I'll remove Hoard from the repository. Fixes #13554. Change-Id: Id2871601b1e99dcf022fbef2c53008ee6c3f233b