gcc下使用tcmalloc(gperftools)2.4的注意事项

版权声明:本文为博主原创文章,转载请注明源地址。 https://blog.csdn.net/10km/article/details/50401005

前几天在折腾项目代码的编译问题,打算使用tcmalloc内存池来管理内存分配。无意中在gperftools的说明文档README中看到了这段话:

NOTE: When compiling with programs with gcc, that you plan to link with libtcmalloc, it’s safest to pass in the flags -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free when compiling. gcc makes some optimizations assuming it is using its own, built-in malloc; that assumption obviously isn’t true with tcmalloc. In practice, we haven’t seen any problems with this, but the expected risk is highest for users who register their own malloc hooks with tcmalloc (using gperftools/malloc_hook.h). The risk is lowest for folks who use tcmalloc_minimal (or, of course, who pass in the above flags :-) ).

说得很明白,当使用gcc来编译项目时,建议加上-fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free这四个编译选项。 看编译选项的名字就知道,这是阻止编译器优化时使用内置版本的malloc,calloc,realloc,free函数。 gcc在优化的时候,假设是使用自己的内置(built-in)的内存管理函数,这种假设在使用tcmalloc时就成问题了。虽然实际应用中目前没有发现任何问题,但还是存在预期风险,所以加上这四个选项是最安全的一种做法。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券