[PATCH] D101427: Linux support for mimalloc as a custom allocator

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D101427#3271170 <https://reviews.llvm.org/D101427#3271170>, @michaeljclark wrote:

> In D101427#3264238 <https://reviews.llvm.org/D101427#3264238>, @MaskRay wrote:
>
>> Perhaps we don't need additional CMake code for using an alternative malloc on Linux.
>> For example, to use mimalloc it is simply `-DCMAKE_EXE_LINKER_FLAGS=-Wl,--push-state,--whole-archive,path/to/libmimalloc.a,--pop-state`
>
> Does this work with `-DLLVM_LINK_LLVM_DYLIB=ON`?

Yes. The linker will export symbols like `malloc` to `.dynsym` in the executable. At run-time, the executable malloc will interpose undefined references from `libLLVM-14git.so`.

In a `-DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_EXE_LINKER_FLAGS=-Wl,--push-state,/tmp/p/mimalloc/out/release/libmimalloc.a,--pop-state -DLLVM_LINK_LLVM_DYLIB=ON` build, `ninja check-lld-elf passes.

> The benefit of adding a build system option is that it encodes this knowledge within the build system. For example, it took me quite a long time to figure out that glibc malloc_hooks are not thread-safe and broken if using shared libraries. If this approach works then perhaps it could be added as one way to do this, but honestly, I find it a bit messy to have a built archive dependency and would prefer to have that as an option along with a standard subdirectory include as there is for Clang and the other modular tools and library dependencies. I am making changes to the allocator and testing them within LLVM so it is quite good to have CMake rebuild the dependency if there are any changes.

This is useful when there is non-trivial logic.
For example, if we need to disable some other features or report a diagnostic when two features are incompatible, having such a toggle may be useful.

For Linux, linking libmimalloc appears a completely orthogonal feature to me.
llvm-project has hundreds of CMake variables and most people don't know most options.
Having this option may just add yet another option which people don't know.

> One approach might be to add a potential LLVM_INTEGRATED_CRT_ALLOC_LIB or LLVM_INTEGRATED_CRT_ALLOC_DYLIB config option that points to an archive or dynamic library, or one variable with suffix detection. It may or may not be possible to use the project-wide linker flags due to address or memory sanitizer as it could interfere with their interposition mechanism? I do not know. I guess it needs testing.
>
>> When linking a default build of chrome (no debug) and a Release build of clang, using libmimalloc.a is 1.12x as fast. LD_PRELOAD=path/to/libmimalloc.so is 1.11x as fast.
>
> Indeed, I found this to be the case too.

Thanks for confirmation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101427/new/

https://reviews.llvm.org/D101427