Jemalloc 5.4.0

"Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d."

Source: https://brand.systemd.io/

An interesting case is "WiFi", short for "wireless fidelity". "Fidélité sans fil" in French should be feminine, but every technical person says "le WiFi" (masculine) while many (most?) non-technical people intuitively say "la WiFi" (feminine).

If you use a thread-local data structure, your allocator can pretend that it is running on a single-core, single-task system.

If you use a CPU-local data structure, you must handle the case where, mid-way through a call to your allocator, the CPU runs a second thread that makes another call to your allocator (and that, too, can get interrupted by another thread that allocates memory, etc.)

That makes thread-local easier to implement and likely faster (it doesn’t require any memory barriers in the fast path)

Also, good schedulers try to avoid moving threads between CPUs. The better they manage to do that, the lower the cost of having per thread data structures (there likely still is a price, as there most of the time are more threads than CPUs on a system)

Memory allocation behaviour has visible impact also for users of managed languages, and the behaviour of software for end users.

In our Python program, a bit of numpy processing of large pictures led to 100 GB not being returned to the OS by glibc's default allocator and the machine running out of memory shortly after. With jemalloc's reliable memory return settings, those problems disappear.

>...the vast majority of software was written in garbage collected language

and even then recently it costed (us) quite a few months to blame JVM and later the default glibc memory allocator for running out native (not java heap memory) - had to exclude all possible native libs (zlib, zstd via jna), direct buffers, sockets, thread stacks and so on. Changing the malloc to jemalloc solved the issue, even though initially it was done for its debugging capabilities.

It's just a great memory allocator.

Because unfortunately, the runtimes belonging to all or at least most of those languages perform a lot better with jemalloc than with the system default.

I wish that wasn't the case, but it is.

TL;DR: Because the runtime of most GC:d languages uses malloc for its internal data structures.

I work for the runtime team of JPG @ Oracle. We use malloc in Hotspot, quite a lot actually! Providing your JVM with a good malloc can improve the performance of the runtime, both in terms of CPU and memory, by quite a bit.

I don't think you need the details, but it's good to be aware that some mallocs are better than others, and there are multiple of them. Being aware of jemalloc is a good way of being aware of the facts I just mentioned :-).

Your experience writing memory allocators is irrelevant. The point is that jemalloc is widely used and that’s why it makes sense to be aware of it.

Writing an allocator is simple, you’re correct, but writing an allocator that doesn’t suck is not simple.

I'd happily see performance, latency and stability of your allocators in massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects.

Writing allocators for domain-specific access patterns is easy. Writing a general-purpose high performing, stable allocator with bounded P99 latency is hard.

Give your friend, Dunning–Kruger, some better pills to keep him from speaking through you.