Webkit has a custom allocator. See http://trac.webkit.org/browser/trunk/Source/bmalloc/bmalloc/..., and, via, http://trac.webkit.org/browser/trunk/Source/bmalloc/bmalloc/..., http://trac.webkit.org/browser/trunk/Source/bmalloc/bmalloc/..., which seems to use mmap and a SYSCALL macro. That doesn't seem to build on the system's alloc.
According to https://www.webkit.org/quality/leakhunting.html, it may even have multiple ones: "Get a fresh WebKit build, ideally a Debug build as this turns off the various custom allocators in WebKit."
It wouldn't surprise me to find custom allocations in many other large projects that may be memory constrained (postgres, open office, gcc, clang, you name it) at some size, the extra burden of a custom allocator isn't that large relative to the size of a project.
Re:LibreSSL – the first 30 days
by chrisrohlf on Sunday May 18, 2014 @08:58PM
(#7765142)
Yes, exactly this. Many large programs have custom allocators for performance and most of them are simple primitives built on top of chunked up pages returned by mmap/VirtualAlloc. The examples of this are all over. This obsession with shaming the OpenSSL developers for wrapping malloc is approaching unhealthy levels.
There was a time about 15 years ago, when many UNIX variants had sub-optimal malloc, or other core libraries, and custom implementations were common in large Open Source projects (as well as commercial products). Those operating systems are mostly gone (Solaris remains, kinda, and there's still some big iron running those old beasts), but I haven't seen a newish project using a custom malloc or other core library in years. I couldn't name the projects that made that choice back then, but I remember seeing it very frequently, when I used to read a lot more C source than I do, today.