Firefox 3附带了一个新的分配器：jemalloc。
我在很多地方都听说过这种新的分配器更好。Google的最佳搜索结果没有提供任何进一步的信息，我对它的工作原理很感兴趣。
Answers:
jemalloc首次出现在FreeBSD上，这是一个“ Jason Evans”（因此是“ je”）的创意。如果我没有写过一个叫做paxos:-)的操作系统，我会嘲笑他过于自负。
有关完整详细信息，请参见此PDF。这是一份白皮书，详细描述了算法的工作方式。
主要好处是多处理器和多线程系统中的可伸缩性，部分是通过使用多个舞台（从中进行分配的原始内存块）实现的。
在单线程情况下，多个竞技场没有真正的好处，因此使用单个竞技场。
但是，在多线程情况下，会创建许多竞技场（竞技场的数量是处理器的四倍），并且以循环方式将线程分配给这些竞技场。
这意味着可以减少锁争用，因为尽管多个线程可以同时调用malloc或free并发调用，但只有在它们共享同一竞技场的情况下它们才会竞争。具有不同舞台的两个线程不会互相影响。
另外，jemalloc由于从RAM提取数据的行为比使用CPU缓存中已存在的数据要慢得多，因此尝试优化缓存的位置（概念上与从RAM快速获取与从磁盘缓慢获取之间没有区别）。为此，它首先尝试最大程度地减少总体内存使用，因为这更有可能确保应用程序的整个工作集在缓存中。
而且，在无法实现的地方，它会尝试确保分配是连续的，因为分配在一起的内存往往会一起使用。
从白皮书来看，这些策略似乎为单线程使用提供了与当前最佳算法相似的性能，同时为多线程使用提供了改进。
有一个有趣的源代码：C源代码本身：https : //dxr.mozilla.org/mozilla-central/source/memory/build/mozjemalloc.cpp（旧）
在开始时，简短的摘要描述了它的大致工作方式。
// This allocator implementation is designed to provide scalable performance
// for multi-threaded programs on multi-processor systems. The following
// features are included for this purpose:
//
// + Multiple arenas are used if there are multiple CPUs, which reduces lock
// contention and cache sloshing.
//
// + Cache line sharing between arenas is avoided for internal data
// structures.
//
// + Memory is managed in chunks and runs (chunks can be split into runs),
// rather than as individual pages. This provides a constant-time
// mechanism for associating allocations with particular arenas.
//
// Allocation requests are rounded up to the nearest size class, and no record
// of the original request size is maintained. Allocations are broken into
// categories according to size class. Assuming runtime defaults, 4 kB pages
// and a 16 byte quantum on a 32-bit system, the size classes in each category
// are as follows:
//
// |=====================================|
// | Category | Subcategory | Size |
// |=====================================|
// | Small | Tiny | 4 |
// | | | 8 |
// | |----------------+---------|
// | | Quantum-spaced | 16 |
// | | | 32 |
// | | | 48 |
// | | | ... |
// | | | 480 |
// | | | 496 |
// | | | 512 |
// | |----------------+---------|
// | | Sub-page | 1 kB |
// | | | 2 kB |
// |=====================================|
// | Large | 4 kB |
// | | 8 kB |
// | | 12 kB |
// | | ... |
// | | 1012 kB |
// | | 1016 kB |
// | | 1020 kB |
// |=====================================|
// | Huge | 1 MB |
// | | 2 MB |
// | | 3 MB |
// | | ... |
// |=====================================|
//
// NOTE: Due to Mozilla bug 691003, we cannot reserve less than one word for an
// allocation on Linux or Mac. So on 32-bit *nix, the smallest bucket size is
// 4 bytes, and on 64-bit, the smallest bucket size is 8 bytes.
//
// A different mechanism is used for each category:
//
// Small : Each size class is segregated into its own set of runs. Each run
// maintains a bitmap of which regions are free/allocated.
//
// Large : Each allocation is backed by a dedicated run. Metadata are stored
// in the associated arena chunk header maps.
//
// Huge : Each allocation is backed by a dedicated contiguous set of chunks.
// Metadata are stored in a separate red-black tree.
//
// *****************************************************************************
但是，缺少更深入的算法分析。
至于http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/（也是mozilla + jemalloc的第一个Google搜索结果），jemalloc给mozilla带来了什么好处：
[...]得出结论，长时间运行后，jemalloc给了我们最少的碎片。[...]在Windows Vista上进行的自动化测试显示，当我们打开jemalloc时，内存使用量减少了22％。
Aerospike于2013年在私人分支机构中实施了jemalloc。2014年，它被并入了Aerospike 3.3。Psi Mankoski刚刚写了Aerospike的实现，以及何时以及如何有效使用jemalloc来实现High Scalability。
jemalloc确实帮助Aerospike充分利用了现代多线程，多CPU，多核计算机体系结构。jemalloc还内置了一些非常重要的调试功能来管理舞台。通过调试，Psi能够分辨出什么是真正的内存泄漏，而不是什么是内存碎片的结果。Psi还讨论了线程缓存和每线程分配如何提供整体性能（速度）的提高。