目前市面上有不少分析Jemalloc老版本的博文,但最新版本5.3.0却少之又少。而且5.3.0的架构与5之前的版本有较大不同,本着“与时俱进”、“由浅入深”的宗旨,我将逐步分析最新release版本Jemalloc5.3.0的实现。
另外,单讲实现代码是极其枯燥的,我将尽量每个原理知识点都用一个简简单单的小程序引出,这样便于大家测试和上手调试。另外,我还会用GDB打印数据结构、变量的值,方便理解当时的状态或算法。
对jemalloc来说最主要的是找到要free的内存块(region)的元信息,比如内存的大小, 它属于哪个bin。因为所有的region都用extent来描述,要free某个region还要找到其对应的extent(edata是用来描述extent的). 以上两个信息都是通过一个叫emap的东西找出来的(可能是extent map的缩写),具体点就是全局变量arena_emap_global.
本节我把bin index, edata等信息称为元信息,本节的重点就是讲解如何通过内存指针得到元信息。
此处用到了一个rtree数据结构,虚拟地址的有效位数决定了这棵树的高度。
#if RTREE_NSB <= 10
# define RTREE_HEIGHT 1
#elif RTREE_NSB <= 36
# define RTREE_HEIGHT 2
#elif RTREE_NSB <= 52
# define RTREE_HEIGHT 3
我的机器上虚拟地址的有效位数是48位,故最高的16位(64-48) 没用,
而且extent的地址(树的叶子节点内容之一)必须是4KB的整数倍,故最低的12位可忽略,NSB就是中间的36位,所以在我的机器上树高为2:第一层为node,第二层为leaf.
下面是一个例子:
//gcc test.c `jemalloc-config --libdir`/libjemalloc.a `jemalloc-config --libs` -g
#include <malloc.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char* argv[])
{
void* arr[300];
for(int i=0;i<300;i++) //tcache bin
{
arr[i] = malloc(10);
}
for(int i=0;i<300;i++) //tcache bin
{
free(arr[i]);
}
return 0;
}
目前要释放的地址为arr[i]= 0x7ffff741d030
从$tidx=1可见要释放的内存属于大小为16byte下标为1的size class. extent的信息也被我们打出来了。
我们这个实例中前几次的free比较简单,并不需要把内存还到extent中(edata_t是用来描述extent的),因为这是small size class而且tcache.bin[1]依然有空间,故前几次的free只需要挪动tcache.bin[1].stack_head. 当tcache.bin[1]没空间时才需要flush 100个到extent(把stack_head下移,往高地址移动),此时才会用到extent信息。
以上这种查找元信息的方式叫hard模式,对应的函数为rtree_leaf_elm_lookup_hard,没有“软”办法才采用这种“硬”办法,那“软”办法是啥哪?
就是通过一个叫rtree_ctx的东西,有两个数组组成, 长成这个样子:
注意:rtree_ctx是tsd的一部分,也就是一个线程有自己的独一份rtree_ctx。
假设要释放的内存由ptr指向,
第一级是cache[16], ptr第31~34位的值做下标(可由rtree_cache_direct_map(ptr)计算)找到相应的元素,然后比较leafkey与rtree_leafkey(ptr),若相等则leaf即是指向二级leaf数组的指针。这里不知道怎么表达才好,我叫它“内存紧凑性”,英文叫locality:程序一段时间内访问或释放内存的地址大概率在一个范围内,比如0x0x7ffff741d000, 0x7ffff781e000, 它们的第31~34位都是一样的。所以这次中了cache[i], 下次中cache[i]的概率极高。
第二级是l2_cache[8],如果第一级比较失败,则挨个比较l2_cache[i].leafkey与rtree_leafkey(ptr),若相等则leaf即是指向二级leaf数组的指针。
不论第一级还是第二级比较成功,则leaf[rtree_subkey(ptr,1)]即为元信息。
保持rtree_ctx的活性(高效)
为了保持其命中率,jemalloc会不停的更新这两个数组,主要代码涉及到两个宏RTREE_CACHE_CHECK_L2及RTREE_GET_LEAF,读者如有兴趣不妨自己看一看。
其更新策略就是:LRU,优先级方面cache>l2_cache[0]>l2_cache[1]>..., 尽量让高优先级的先中,如果后面的中了则把中了的值交换到cache, cache原来的值降级到下一级。
每次查找,
1. 如果cache中,什么也不做。
2. 如果l2_cache[0]中(l2_cache[0]==leafkey which is rtree_leafkey(ptr))
3. 如果l2_cache[i]中,
4. 如果谁都没中