Hacker News Reader

Comment by smallstepforman | Hacker News Reader

Before a majority of Operating Systems adopted Bonwicks Slab allocator, custom allocators made sense. These days, it's best to let the OS worry about the allocations since it knows about available storage devices (eg. NNVM), cache levels and threads, power management, etc, and it can return overallocated (yet unused) memory which custom allocators cannot.

View on HN

FWIW: all allocators tested are user-space allocators - and moreover, to achieve this kind of performance they MUST be user-space (as user-kernel switch with all the checks is waaaay too expensive). And as soon as we're user-space - it IS possible to compete with whatever-allocator-is-provided-by-your-user-space-lib (not that it makes sense for 99.9% of the projects, but it MIGHT be possible to write an allocator which is better-than-<whatever-allocator-we-pick>). In addition, it IS possible to write allocators MUCH-better-suited-for-specific-apps (see, for example, talk on Arena Allocators on CPPCON17 by John Lakos from Bloomberg).

On POSIX systems at least, the API provided to userspace to allocate memory is too low level to remove the need for a higher level allocator, so you will be using a separate allocator.

> and it can return overallocated (yet unused) memory which custom allocators cannot.

These allocators allocate memory out of buffers they've gotten from the kernel, so overallocation is very much possible depending on your kernel config.

Yep, this two layer approach is also desirable since in userspace you aren't context switching to the kernel all the time and can make some assumptions to avoid certain locking and external fragmentation with the kmem. Short lived allocs are really cheap coming out of i.e. jemalloc arenas and that is important for a lot of programming ergonomics.

OS allocators allocate pages, userspace allocators use the OS allocator to allocate bytes.

Reply on news.ycombinator.com