带jemalloc的C++ STL

Question

如何将C++ STL容器与jemalloc (或任何其他malloc实现)结合使用？

它是否像包含jemalloc/jemalloc.h一样简单？或者我应该为他们写一个分配器？

编辑：我正在开发的应用程序在其生存期内分配和释放相对较小的对象。我希望替换默认的分配器，因为基准测试表明应用程序不会扩展到两个核心之外。分析显示，它正在等待内存分配，这就是导致缩放问题的原因。据我所知，jemalloc将在这方面提供帮助。

我希望看到一个解决方案，这是平台中立的，因为应用程序必须同时在Linux和Windows上工作。(在Linux下，与不同的实现链接是很容易的，但据我所知，在Windows上很难。)

Answer 1

C++允许您使用替换 operator new。如果这个替换的operator new调用je_malloc，那么std::allocator将间接调用je_malloc，然后所有标准容器都会调用je_malloc。

这是迄今为止最简单的方法。编写自定义分配器需要编写整个类。替换malloc可能是不够的(不能保证未替换的operator new调用malloc)，而且它具有禤浩焯McCarthy先前指出的风险。

Answer 2

如果您想在程序中的任何地方替换malloc (这是我想要的，而且似乎也是唯一的逻辑解决方案)，那么您所要做的就是链接到它。

因此，如果您使用gcc ，那么您所要做的就是：

g++ yourprogram.cpp -ljemalloc

但是，如果不可能，则必须通过另一个函数(如jemalloc和je_free )使用new，然后必须重载new和delete运算符。

如果不使用特定于实现的特性(主要是统计数据)，就不需要包含任何标题。

Answer 3

编写分配器将是最简单的解决方案，因为stl被设计为具有可互换的分配器。这将是最简单的道路。

有些项目玩游戏，试图让替代的malloc实现取代编译器的配套库提供的malloc和new。这很容易出现各种问题，因为您最终依赖于编译器的具体实现细节以及它通常使用的库。这条路充满了危险。

试图在全球范围内取代malloc 的一些危险：

• 静态初始化程序顺序在C++中有有限的保证。除非禁止可能分配内存的静态对象，否则无法保证在第一个调用方尝试使用它之前初始化分配程序替换。运行时没有这个问题，因为编译器和运行时一起工作，以确保在初始化任何静物之前运行时是完全初始化的。
• 如果动态链接到运行库，则无法确保运行库的某些代码不绑定到自己的实现。在重新分发应用程序时，试图修改编译器的运行时库可能会导致授权问题。
• 所有其他分配方法都不一定总是依赖于malloc。例如，new的实现可能绕过malloc进行大量分配，并直接调用OS来分配内存。这需要跟踪，以确保此类分配不会意外地发送到替换的free。

我相信Chromium和Firefox都已经取代了分配器，但它们玩了一些肮脏的把戏，而且随着编译器、链接器和运行时的发展，它们可能不得不更新它们的方法。