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

[Jez Ng via Phabricator via llvm-commits]

int3 requested changes to this revision.
int3 added a comment.
This revision now requires changes to proceed.

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

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.)

> (Conceptually the bump-allocator can be implemented without locks using atomic incr', but looking at the current impl, I kind of got discouraged as it seemed too complex)

Yeah, I'd taken a look at it too and it does seem like a bunch of work. I'm thinking that we could maybe (eventually) do a hybrid solution where we use regular mutexes for the infrequently-called new-slab-allocation codepath, and atomic CAS for the fast pointer bump.

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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121635