今年年初由于facebook而火起来的jemalloc广为人之，但殊不知，它在malloc界里面很早就出名了。Jemalloc的创始人Jason Evans也是在FreeBSD很有名的开发人员。此人就在2006年为提高低性能的malloc而写的jemalloc。Jemalloc是从2007年开始以FreeBSD标准引进来的。软件技术革新很多是FreeBSD发起的。在FreeBSD应用广泛的技术会慢慢导入到linux。
目前jemalloc在firefox中也在使用。在firefox2中出现了内存碎片问题之后，便在firefox3中使用了jemalloc。在safari和chrome中使用的是google的tcmalloc。
Jemalloc的技术特性
Jemalloc聚集了malloc的使用过程中所验证的很多技术。忽略细节，从架构着眼，最出色的部分仍是arena和thread cache。（事实上，这两个与tcmalloc的架构几乎相同。Jemalloc only的部分将会在另一次posting中继续探讨。）
Arena
与其像malloc一样集中管理一整块内存，不如将其分成许多个小块来分而治之。此小块便称为arena。让我们想象一下，给几个小朋友一张大图纸，让他们随意地画点。结果可想而知，他们肯定相互顾忌对方而不敢肆意地画（synchronization），从而影响画图效率。但是如果老师事先在大图纸上划分好每个人的区域，小朋友们就可以又快又准地在各自地领域上画图。这样的概念就是arena。
Thread cache
如果是开辟小块内存，为使不参照arena而直接malloc，给各自的线程thread cache领域。此idea是google的tcmalloc的核心部分，亦在jemalloc中体现。
再拿上面的例子，这次给小朋友们除了一张大图纸外，再各自给A4纸一张。这样，小朋友们在不画大面积的点时，只在自己的A4纸上心情地画即可（no arena seeking）。可以在自己手上的纸上画或涂（using thread cache），完全不用顾忌别人（no synchronization, no locking），迅速有效地画。
下图是jemalloc的核心layout。看着复杂，其实都是上面说明的部分。
实际jemalloc的性能呢？
最左边的就是glibc的malloc，最右边的就是jemalloc。从图表上可以看出，jemalloc的性能有glibc的两倍以上。非常压倒性的性能差异。因此，使用了jemalloc的应用程序自然会快很多。Jemalloc旁边的就是tcmalloc。Tcmalloc的性能与其相差甚微，低jemalloc2.1.0慢4.5%。图上和tcmalloc的1.4版本，而如今它已经到了1.6版本，因此实际上这两者应该是不相仲伯的。Jemalloc的创始人jason evans也意识到这一点，说在cpu core 8以上的计算机上jemalloc效率更高。
给程序员的最后的免费午餐 – kth分布式技术lab的实例
2005年发表了一篇文章“免费午餐的时代结束了”。在之前，程序就算不用费脑子，随着cpu时钟速度增加，程序性能自己就会上去。但现在不同，现在cpu时钟趋于稳定，而核数不断地增加。程序员需要适应这样的多线程多进程的环境，并要开发出适合的程序。文章讲的大概是这样的内容。
6年之后的如今，这篇文章完全变成现实了。事实上cpu时钟停留在3GHz，而核不断上升。现在程序要适应多线程多进程的分布式计算，速度才能上升。但是这样的程序很难。
现在在多线程的环境下，给程序员们的最后一道午餐便是tcmalloc，jemalloc这样的malloc library。对于使用多线程的程序而言，性能会提高数十%。
共享一下我本人的经验。我本人在kth技术研究所分布式技术lab中承担iLock（分布式同步工具，请参考google的chubby）。在iLock中用了google的tcmalloc的结果，性能提升了18~22%。
最大的优点就是你不需要做任何复杂的工作便可得到这样的效果。不需要代码重编译。只需在执行二进制之前，在cmd窗口中输入
$ LD_PRELOAD=”tcmalloc所设置的文件夹/libtcmalloc.so”
这样在之后执行的应用程序会使用tcmalloc或jemalloc，从而代替glibc标准malloc（ptmalloc）。这需设置此处，我们便可得到性能20%的提升，这真可谓是送给我们的最后的免费午餐。
如今，在分布式技术lab中使用google的tcmalloc。原因在于性能上两者差不多，但google的tcmalloc所提供的程序分析工具非常（heap profiler, cpu profiler）丰富。所以tcmalloc可能更方便一些。
一定要使用最新的malloc么？一定要的！