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

[Michael via Phabricator via llvm-commits]

michaeljclark added a comment.

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`?

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.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101427