【问题标题】:Using tcmalloc in a shared library在共享库中使用 tcmalloc
【发布时间】:2021-02-22 08:09:57
【问题描述】:

我有许多与 tcmalloc (.a) 链接的可执行文件。 我通常在可执行级别执行此操作,以便可执行文件加载的任何共享库都受益于 tcmalloc。

但是,我有一个需要向用户提供 .so 库的场景。

在那个共享库中使用 tcmalloc 可以吗?

如果用户的可执行文件本身没有与 tcmalloc 链接会发生什么?

谢谢。

【问题讨论】:

  • 如果使用 tcmalloc 极大地提高了库的性能,那么最好将库与它链接起来,但应用程序可能有其他不适合 tcmalloc 的内存分配模式.因此,至少要做到这一点,以便您对 tcmalloc 的使用是私有的(请参阅答案)。如果您的库的性能并不真正依赖于 tcmalloc,那么我根本不会链接它,而是让应用程序来决定使用什么内存分配器。

标签: c++ tcmalloc


【解决方案1】:

在那个共享库中使用 tcmalloc 可以吗?

这取决于几件事:

  • 您的共享库是否以将mallocoperator new 公开为外部符号的方式与tcmalloc 链接。通常是这样。
  • 库的用户是链接到您的库还是在运行时使用dlopen 加载它,以及使用了哪些dlopen 选项。

如果用户的可执行文件本身没有与 tcmalloc 链接会发生什么?

可能会发生以下两种情况之一:

  1. malloc 已经是用户应用程序/进程中的已解析符号。在这种情况下,您的 .so 使用 malloc。当用户使用dlopen 加载您的.so 时,就会发生这种情况。
  2. malloc 尚未解决,因此用户的应用程序/进程使用来自.so 的 tcmalloc 中的 malloc。当用户在链接器命令行中链接到您的 .so 并且您的 .so 位于 -lc 之前时,就会发生这种情况。

对于您的.so 来说,完全不链接 tcmalloc 可能是最强大的。然后,应用程序的用户可以通过链接 tcmalloc 或其他分配器来决定使用哪个 malloc 实现,或者通过在运行时使用 LD_PRELOAD 预加载不同的分配器来尝试不同的分配器。

您可能想学习how Unix linkers work,以便将来自己回答这些问题。

【讨论】:

猜你喜欢
  • 2015-09-30
  • 2019-01-21
  • 1970-01-01
  • 2015-09-19
  • 2022-01-04
  • 1970-01-01
  • 1970-01-01
  • 2020-11-18
  • 1970-01-01
相关资源
最近更新 更多