[PATCH] D121635: [lld][macho][elf] Teach the bump-allocator in lld/Common about thread-safetiness.

[Vy Nguyen via Phabricator via llvm-commits]

oontvoo added a comment.

In D121635#3380515 <https://reviews.llvm.org/D121635#3380515>, @int3 wrote:

> This doesn't fix race conditions between `StringSaver` and `make<>`, since StringSaver calls the BumpPtrAllocator directly (without going through SpecificBumpPtrAllocator.)

ok - that's an orthogonal  problem :)

> I was thinking that we could fix https://github.com/llvm/llvm-project/issues/54378 for now by replacing `make<TrieNode>()` by `new TrieNode()`, i.e. using the system allocator instead of the BumpPtrAllocator. (Then `~TrieBuilder` could handle the freeing.)

sure, i'm fine with a quick/temp fix for this

> Another option is to use the system allocator whenever we need concurrent allocations, and add some cmake flag that allows us to easily switch to `rpmalloc` or `jemalloc`.

I think the current problem is that, a given piece of code doesn't know it should be thread-safe or not.  It'd seem weird to have x parts of the linker use a thread-safe allocator, then y remaining parts don't ...
Whichever allocator we end up using, I think it should be use across the whole linker ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121635