九浅一深Jemalloc5.3.0 -- ⑧浅*free

深山老宅

已于 2024-07-08 09:08:23 修改

阅读量1.8k

点赞数 53

分类专栏： jemalloc 5.3.0 文章标签： jemalloc 5.3.0 内存分配内存管理 malloc free

于 2024-07-04 07:00:00 首次发布

本文链接：https://blog.csdn.net/zhaiminlove/article/details/139936667

版权

jemalloc 5.3.0 专栏收录该内容

12 篇文章 1 订阅

订阅专栏

目前市面上有不少分析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）没用，

configure会检测虚拟地址的有效位数，如下：

$./configure --enable-debug

...
checking number of significant virtual address bits... 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)）