深入了解tcmalloc（一）：windows环境下无缝拦截技术初探

最新推荐文章于 2023-10-10 01:06:08 发布

蜗牛_Wolf

最新推荐文章于 2023-10-10 01:06:08 发布

阅读量1.1k

点赞数

分类专栏： tcmalloc

原文链接：https://blog.csdn.net/sharemyfree/article/details/47339497

版权

tcmalloc 专栏收录该内容

3 篇文章 1 订阅

订阅专栏

概述：

又到了一个总结提炼的阶段，这次想具体聊聊游戏引擎中使用的内存管理模块tcmalloc组件的使用心得。项目的前期曾经遇到过内存瓶颈，特别是windows系统下的客户端程序在经历长时间运行之后会出现内存占用率很高疑似泄漏的现象，排查了很久都没有找到原因，甚至一度无法定位问题出自游戏脚本层还是引擎层，后来在引擎中链接了tcmalloc组件，通过实时dump程序的内存信息最终找出了泄漏的元凶。tcmalloc的另一个优势就是通过高效率内存分配来提高游戏运行时性能，不得不说在使用tcmalloc之后，整个游戏的稳定性和效率都有了很大的提升。为了今后更有效和稳定地使用tcmalloc组件，就在这里深入剖析一下这个神器。Tcmalloc是Google Perftools中的一个组件，提供一整套高效健壮的内存管理方案，比传统glibc的内存分配和释放要快数倍；其次，基于tcmalloc之上的heapprofiler可以实时dump程序中heap的使用信息，是一个很好的检测内存泄漏的辅助工具；同时tcmalloc的使用又是极其方便，只需要在编译时增加一个链接选项，就可以无缝拦截(patch)原生操作系统运行库中的内存分配和释放接口，而无需修改已经完成的项目工程代码，大大减少移植整合的成本。

在windows平台下，tcmalloc可以通过静态库或者动态库(DLL)的形式嵌入到工程里面，这里将主要分析tcmalloc如何DLL动态链接到工程里面，同时将重点剖析一下tcmalloc如何在不改变工程原有代码的前提下无缝地拦截windows原生内存管理接口。

配置步骤：

以DLL形式链接进入工程的主要步骤如下：首先从官网下载并解压gperftools包，下载地址为：http://code.google.com/p/gperftools/downloads/list，现有的版本是2.1；打开并编译gperftools-2.1目录下的gperftools.sln；编译通过后，在build输出目录下生成libtcmalloc_minimal.dll和对应的lib文件；将lib和dll文件拷贝到工程编译目录下，并在链接选项中添加两个配置，如下图所示：additional dependencies(附加依赖项): libtcmalloc_minimal.dll； force symbol references(强制符号引用):__tcmalloc (64bit 系统)；重新编译链接后，exe运行时tcmalloc将在程序静态变量初始化阶段拦截所有原生内存管理接口。

无缝链接原理剖析：

要理解tcmalloc如何无缝拦截底层运行库(runtime library)中的内存管理函数，首先需要理解windows平台下的可执行文件和 exe加载流程。windows平台下的可执行文件是以PE(Portable Executable)格式存在的，由各个不同的段组织而成，如.data .text .rsrc等，其中.text段包含了模块内所有代码的二进制输出，相应的函数调用是以

call XXXXXXXX

的汇编指令存在，其中XXXXXXXX表示程序运行时的函数虚拟地址。由于本模块PE文件各个段的布局和相应加载地址是在链接时决定，所以对于本模块内的函数调用可以在链接时就计算得到相应的函数地址，如下图所示，对某.text段中的.func函数进行调用，.func函数地址XXXXXXX可以通过将该段的加载地址和函数在段内的偏移两者相加得到：

对于隐式(implicit)链接的DLL模块，由于链接器无法在链接阶段得到DLL模块中各个段的布局和加载信息，所以无法直接计算得到具体函数地址。如果其他模块需要调用DLL内的函数，PE文件通过一种称为引用地址数据表(Import Address Table, IAT)的数据结构间接指向这些函数，在链接阶段链接器简单在IAT中写入各个函数的symbol，而相应的call指令也变成了如下形式：

CALL DWORD PTR [XXXXXXXX]

其中[XXXXXXXX]表示.func函数在IAT中相应slot的地址，如下图所示，XXXXXXXX值是由IAT表的加载地址和.func的slot index两者相加得到的：

当这个可执行文件加载运行时，windows的程序加载器(Loader)负责解析这个PE文件格式，将文件中的各个数据段和代码段映射到进程的地址空间，同时通过遍历IMAGE_IMPORT_DESCRIPTOR 段，将所有隐式链接的DLL都加载到内存中，同时更新各个IAT中的slot，写入symbol所对应函数所在的内存地址，这样就保证了指令CALL DWORD PTR [XXXXXXXX]可以正确地调用到其他模块中的函数。

内存管理模块一般由操作系统底层运行库(runtime library)或第三方库提供，以动态或者静态的方式链接入可执行文件，拦截这些函数的方法一般有两种：

1）对需要拦截的内存管理函数，修改所有本地对其call指令的目的地址和IAT slot中可能引用到的间接函数地址，将它们指向新的替换函数地址，如下图A所示：

图A，main module是可执行文件，module B是底层运行库或者实现了内存管理的第三方库，module A是tcmalloc，tcmalloc需要拦截所有module的IAT表中原来调用module B中malloc的slot，同时还要拦截所有module B中本地调用malloc的call指令，将他们都拦截到tcmalloc中相应的替换函数。

2）直接修改需要拦截的内存管理函数实现，将函数空间的前几个bytes修改成一个跳转指令，跳转到新函数的地址空间，如下图B所示：

图B,tcmalloc保留所有module的IAT内容和本地call指令，只修改module B中malloc的实现，将最前面bytes修改成一个jmp指令，将程序的指令流跳转到tcmalloc中相应的提替换函数。

Google的tcmalloc组件正是以第二种方式无缝拦截了内存管理函数，修改原有目标函数的前kRequiredTargetPatchBytes（5）字节，将程序强制跳转到tcmalloc自己的内存管理函数。当然tcmalloc更为周到地考虑了以下几点：

tcmalloc接管了底层运行库和第三方库中的整套内存管理方案，拦截了各模块中所有的内存管理函数：malloc, free, realloc, calloc, new, newArray, delete, deleteArray, newNothrow, newArrayNothrow, kDeleteNothrow, deleteArrayNothrow, msize, expand, callocCrt
准确区分程序运行时各个内存空间的分配者，严格遵循由谁分配则由谁负责释放的原则，程序在tcmalloc拦截前申请分配的内存空间由原始内存释放函数进行释放，在tcmalloc拦截后申请分配的内存空间由tcmalloc的内存释放函数进行释放，保证整个程序运行正确性和最终dump信息的准确性；
保证每个内存管理函数只会被拦截一次，对某些DLL中export forwarding的内存管理函数，tcmalloc会遍历整个export链找到最终的实现函数进行拦截；
对于显示(explict)链接的DLL库，tcmalloc通过拦截loadLibrary, LoadLibraryExW, FreeLibrary等module操作函数来做到拦截这些模块中的内存管理函数
tcmalloc考虑了unpatch的过程，上层程序可以通过适当的操作，恢复到原始运行库提供的内存管理方案，所以tcmalloc实现中不仅要修改目标函数的内容，还需要将被修改前的内容进行保存，在适当的时候进行还原。

单一函数拦截流程：

下面从tcmalloc如何拦截单个内存管理函数开始介绍，文件preamble_patcher_with_stub.cc中的函数

1	`SideStepError PreamblePatcher::RawPatchWithStub(void* target_function,` `void* replacement_function, unsigned` `char* preamble_stub, unsigned` `long` `stub_size, unsigned` `long* bytes_needed)`

实现了对单个函数的拦截逻辑，整个流程中涉及了三个至关重要的变量，他们指向的三个地址空间，理解这三个地址空间含义也就理解了tcmalloc的整个拦截流程：

target_function：需要被拦截的目标函数地址，譬如运行库的malloc函数地址；
replacement_function：tcmalloc中用来替换被拦截函数的新函数地址，譬如tcmalloc中的Perftools_malloc函数就是拦截运行库malloc函数后的替换函数；
preamble_stub：用来存放目标函数起始几个bytes内容的空间，这个空间是tcmalloc通过函数AllocPageNear额外申请的，具体有两个作用将下面介绍；

这个三个变量对应函数的前三个参数，函数的后两个参数相对比较简单：

stub_size：表示preamble_stub内存块的总大小；

bytes_needed：作为返回值，传递给函数的调用者该拦截过程实际占用preamble_stub的字节数。

拦截流程具体如下：

while (读取目标函数的内容偏移量(preamble_bytes)小于kRequiredTargetPatchBytes) {

// 反汇编得到相应的指令类型

InstructionType instruction_type =

disassembler.Disassemble(target + preamble_bytes, cur_bytes);

if (IT_JUMP == instruction_type) {

// 如果是跳转指令

1）将指令类型字节码拷贝到preamble_stub

2）重新计算该指令相对跳转偏移original_jump_dest - stub_jump_from，并拷贝到preamble_stub，保证该迁移后的指令在执行时能够正确跳转到原来指令应该跳转到的目的地址，如果原目的地址在需要迁移kRequiredTargetPatchBytes的字节内，则还需要再一次重新计算相对跳转偏移到新的目的地址。

} else if (IT_GENERIC == instruction_type) {

if (IsMovWithDisplacement(target + preamble_bytes, cur_bytes)) {

// 如果是mov displace指令

1）将指令类型字节码拷贝到preamble_stub

2）重新计算mov的目的地址，逻辑与上面处理跳转指令类似

} else {

// 其他普通指令

1）将整个指令简单copy到preamble_stub

}

// 将读取目标函数内容的指针向后偏移刚刚copy的指令字节数

preamble_bytes += cur_bytes;

}

if (NULL != bytes_needed)

// 计算preamble_stub会被占用的字节数

*bytes_needed = stub_bytes + kRequiredStubJumpBytes

+ required_trampoline_bytes;

// Now, make a jmp instruction to the rest of the target function (minus the

// preamble bytes we moved into the stub) and copy it into our preamble-stub.

// find address to jump to, relative to next address after jmp instruction （注释很清晰，不多解释）

int relative_offset_to_target_rest

= ((reinterpret_cast<unsigned char*>(target) + preamble_bytes) -

(preamble_stub + stub_bytes + kRequiredStubJumpBytes));

// jmp (Jump near, relative, displacement relative to next instruction)

//在preamble_stub的最后添加一条特殊jmp指令ASM_JMP32REL，其目的是保证上面所提到的2，5需求能正确实现，当程序需要调用原来target_function时，在执行preamble_stub最前几个bytes指令后能够成功跳转到原来target_function空间在kRequiredStubJumpBytes后的指令序列继续执行

preamble_stub[stub_bytes] = ASM_JMP32REL;

// copy the address

memcpy(reinterpret_cast<void*>(preamble_stub + stub_bytes + 1),

reinterpret_cast<void*>(&relative_offset_to_target_rest), 4);

// Inv: preamble_stub points to assembly code that will execute the

// original function by first executing the first cbPreamble bytes of the

// preamble, then jumping to the rest of the function.

// Overwrite the first 5 bytes of the target function with a jump to our

// replacement function.

// (Jump near, relative, displacement relative to next instruction)

// 所有准备工作结束，万事俱备开始真正拦截，往目标函数的前kRequiredStubJumpBytes写入一个跳转指令，跳转到tcmalloc的替换函数

target[0] = ASM_JMP32REL;

// Find offset from instruction after jmp, to the replacement function.

// 计算tcmalloc替换函数的相对地址

int offset_to_replacement_function =

reinterpret_cast<unsigned char*>(replacement_function) -

reinterpret_cast<unsigned char*>(target) - 5;

// complete the jmp instruction

memcpy(reinterpret_cast<void*>(target + 1),

reinterpret_cast<void*>(&offset_to_replacement_function), 4);

// 圆满完成

下图是拦截之后三个空间所包含的内容:

图中黄色部分表示tcmalloc所做的修改，preamble_stub最初的kRequiredStubJumpBytes字节内容是target_function最前面kRequiredStubJumpBytes字节内的指令经过相对地址重计算后的替代指令；kRequiredStubJumpBytes字节后面跟着一条JMP指令用来跳转到target_function中第（kRequiredStubJumpBytes + 1）byte地址空间；JMP指令后还跟着几条trampoline指令，用来处理preamble_stub和target_function的地址空间间隔超过4G的情况，这里不做过多介绍。target_function最前面kRequiredStubJumpBytes字节用一个JMP指令替代，跳转到tcmalloc的replacement_function的地址空间。从中可以看到preamble_stub的作用其实有两个：

当tcmalloc拦截原始的内存管理函数后，如果需要调用target_function函数，譬如释放tcmalloc拦截前已经分配的内存空间，则只需要call preamble_stub就可以实现。
当需要unpatch内存管理函数时，只需要对preamble_stub前kRequiredStubJumpBytes字节内的指令进行patch的逆操作，并拷贝回target_function的空间就可以了。