[PATCH] D122922: [lld][common][lld-macho][lld-coff] Support per-thread allocators and StringSavers

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a subscriber: lattner.
MaskRay added a comment.

In D122922#3436091 <https://reviews.llvm.org/D122922#3436091>, @aganea wrote:

> Hello! Thanks for adding me :-) Interesting challenge!
>
> It's a bit sad that we have to do all this high-level/application-level memory management. Most modern allocators already support (lock-free) per-thread memory pools out-of-the-box, along with migration between threads and to the global pool/arena. This patch seems to be needed solely because we use BumpPtrAllocator/SpecificBumpPtrAllocator. I wonder how things would perform with just using malloc() instead + a modern underlying allocator (rpmalloc, mimalloc, ...). Memory locality brought by the bumpalloc is important, but it'd be interesting to compare benchmarks. FWIW there were discussions with @lattner at some point about integrating rpmalloc into the LLVM codebase, but I never got to post a RFC.

I think the most important reason that we need `llvm::SpecificBumpPtrAllocator<T>` is for its destructors.
In lld, we allocate many objects with non-trivial destructors. `make<T>(...)` allows us to be lazy and not think of the destructor.
I have actually replaced many `make<T>(...)` singleton usage in lld/ELF with `std::make_unique<T>(...)` to save code size.

The second benefit is application-level memory management is more efficient when prudently used.
Whatever lock-free scheme is used, the system malloc will have higher overhead than a use case where objects are rarely used (bump allocator).
Very few classes in lld actually need this, but we abused `make<T>(...)` for almost everything because of its ease of use.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122922