[llvm] Reduce llvm-gsymutil memory usage (PR #91023)

Kevin Frei via llvm-commits llvm-commits at lists.llvm.org
Thu May 16 22:02:37 PDT 2024


kevinfrei wrote:

> > > > > Per my understanding, these two mutex are required to protect any read/write to DieArray field? If so, there seem to be many more accesses of this field not protected?
> > > > 
> > > > 
> > > > They're there for protecting the allocation+population, or destruction of the DieArrays, not generally reading/writing those fields. There needs to be two (for just the first CUDie, and then the whole array) as populating the first can trigger a request to populate the rest.
> > > 
> > > 
> > > What is the code path for that?
> > 
> > 
> > Sorry: I wrote that backwards (fixed the original comment). Populating the full array can trigger a request to populate the CuDie through `determineStringOffsetsTableContribution`, which is why you need the two different locks. The first is always created before the list, but you need to lock it separately so that the read-lock will be free to return just the CUDie.
> 
> Glanced at the code. I think I am missing something. How can code through determineStringOffsetsTableContribution trigger the path? It just accesses StrOffset Section.

Yeah, I didn't see it by looking at the code, because the recursion occurs inside getUnitDIE() (in the .h file), which calls extractDIEsIfNeeded(...)

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


More information about the llvm-commits mailing list