From Michael Lotz <mmlr@xxxxxxxx>:
Michael Lotz has uploaded this change for review. (
https://review.haiku-os.org/800
Change subject: rpmalloc: Import and set as default.
......................................................................
rpmalloc: Import and set as default.
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 where 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 (39.0s -> 37.9s real / 52.8s -> 49.7s user)
when doing the "HaikuDepot compile" benchmark. Memory usage by
app_server, launch_daemon, and Tracker with a handful of windows
after a cold boot changed negligibly (launch_daemon: 444K -> 284K,
app_server: 16.70MB -> 17.05MB, Tracker: 7.50MB -> 8.22MB -- mostly
due to the fact that a heap object is required per-thread now.)
TODO: WebKit hits an apparently unrelated assert failure with
this allocator; probably a race condition?
TODO: test long uptimes (it will probably do better than hoard,
as it can unmap memory in a way hoard can't)
TODO: notify community before merge, so they can keep an eye out
---
M src/system/libroot/posix/Jamfile
A src/system/libroot/posix/rpmalloc/Jamfile
A src/system/libroot/posix/rpmalloc/rpmalloc.cpp
A src/system/libroot/posix/rpmalloc/rpmalloc.h
A src/system/libroot/posix/rpmalloc/wrapper.cpp
5 files changed, 2,358 insertions(+), 1 deletion(-)
git pull ssh://git.haiku-os.org/haiku refs/changes/00/800/1
--
To view, visit https://review.haiku-os.org/800
To unsubscribe, or for help writing mail filters, visit
https://review.haiku-os.org/settings
Gerrit-Project: haiku
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I33d5adacca1ec027c982e88d893a240d969d28f6
Gerrit-Change-Number: 800
Gerrit-PatchSet: 1
Gerrit-Owner: Michael Lotz <mmlr@xxxxxxxx>
Gerrit-Reviewer: waddlesplash <waddlesplash@xxxxxxxxx>
