From waddlesplash <waddlesplash@xxxxxxxxx>:
waddlesplash has uploaded this change for review. (
https://review.haiku-os.org/790
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.
TODO: comparison for memory usage on cold boots
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,356 insertions(+), 1 deletion(-)
git pull ssh://git.haiku-os.org/haiku refs/changes/90/790/1
--
To view, visit https://review.haiku-os.org/790
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: Id2871601b1e99dcf022fbef2c53008ee6c3f233b
Gerrit-Change-Number: 790
Gerrit-PatchSet: 1
Gerrit-Owner: waddlesplash <waddlesplash@xxxxxxxxx>
