[llvm] Reduce llvm-gsymutil memory usage (lambda-free, and less locking) (PR #97640)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> > I guess LLDB would probably enjoy some of the benefits of parallelism in parsing DWARF (maybe - mostly it does it so lazily that there's little to parallelize at any one point in time - except when the input doesn't have an index, in which case it parses it all/indexes up front, but that's not the main case)
> 
> Honestly, the most pleasant way I've seen deeply interactive systmes like LLDB do things in both a parallel & lazy fashion is by using coroutines (async/await). I really wouldn't suggest trying to build something that isn't fully supported by the language & runtime. So, maybe when LLVM/LLDB bumps the language standard to C++20?

Yeah, perhaps.

> anyway...
> 
> I spent about a day chasing the constantly growing list of DWARFUnit functions that might call `extractDIEsIfNeeded` just from inside the gsymutil scenario and hoisting them to the DWARFContext API before declaring it a total loss. I'm not particularly well informed about the general data schema of this stuff, but GSYM transformation is operating at the DWARFUnit level, and trying to make the DIE creation/destruction thread-safe at the DWARFContext level just doesn't 'fit' with the abstraction layers of the system at all :(

Ah, I was thinking of something jankier. Just the code/locking you already have, essentially, but calling into DWARFContext with a lambda to do the work under the lock DWARFContext has. Yeah, not great, but does mean not introducing more locks/broadening the scope of "where to look" to understanding the locking scheme, to some extent.

Does that make sense?



https://github.com/llvm/llvm-project/pull/97640