[PATCH] D140841: [DWARFLinkerNext] Add StringPool class.

[Greg Clayton via Phabricator via llvm-commits]

clayborg added a comment.

In D140841#4024471 <https://reviews.llvm.org/D140841#4024471>, @avl wrote:

> In D140841#4023979 <https://reviews.llvm.org/D140841#4023979>, @dblaikie wrote:
>
>> We probably already have a few StringPools kicking around in LLVM - a multithreaded one sounds like something LLDB already uses (it has a core StringPool for interning strings) - any chance the LLDB one could be sunk into LLVM and reused for your use case as well, for instance?
>
> I am not sure that found the right piece of lldb code:
>
> "lldb/Core/UniqueCStringMap.h" - this one is not multi-thread.
> "lldb/Core/ThreadSafeDenseMap.h" - this one looks to be not effective in heavy multi-thread environment. It locks the whole table for every operation. In heavy multi-thread environment threads would wait each another.
>
> Thus, it looks like both of them are not good candidate.

I think the code David is talking about is in ConstString.cpp. LLDB uniques strings so that it can compare strings by comparing pointers in a unique string pool. This string pool is thread safe and goes to great length to reduce any lock contention. You might be able to loot some code from there if needed.

This approach seems to avoid that contention by creating thread local string pools? Those would then need to be merged later?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140841