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
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our OpenGrok servers:
- http://xref.plausible.coop/ (provided by Landon Fuller)
- http://code.metager.de/source/xref/haiku (provided by MetaGer)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.