>it looks like it avoids atomics on common cases of malloc and free. That’s a big deal and not all malloc a accomplish that.

Many mallocs implementations try to avoid one cache per thread because it can waste a huge amount of memory in applications with thousands of threads opting for per cpu pools or similar solutions. These solutions help with contention but still require atomics (unless using something like restartable sequences).

It is a trade-off, but for applications that use one thread per cpu, completely private free lists can branch win of course.

All modern allocator implementations I am aware of (including Hoard and Mesh) use per-thread caches (of a limited size), and thus avoid the use of atomic operations in the common case while also avoiding blowup (wasted memory caused by using a memory allocator that "leaks" -- see the Hoard paper (ASPLOS 2000, https://people.cs.umass.edu/~emery/pubs/berger-asplos2000.pd...) for a full discussion).

Does hoard avoid atomic ops on the common case of both malloc and free?

This is quite possibly an uninformed question, but is it possible to use multiple allocator implementations simultaneously in the same program?

Obviously this would introduce additional creative ways in which to mess up memory management, but at least theoretically it seems like it ought to be doable. When I tried to search for information on the topic just now, I found only a few items about using multiple allocators in C++ that involved the STL and templates, but nothing about low level code or best practices.

Yeah you can but then you pay a tax on free() because you have to do some dispatch to decide what algorithm you are using. The more algorithms the higher the tax.

Also, you want to make sure that the mallocs can share free pages with each other directly. Otherwise you will likely het higher peak memory overhead or worse perf or both.

The systwm allocator on macOS supports multiple "zones", which can each be backed by different allocators.