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

Kevin Frei via llvm-commits llvm-commits at lists.llvm.org
Tue May 14 09:40:15 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: Wrote that backwards. Populating the whole array can trigger demand population of the UnitDIE through the function `determineStringOffsetsTableContribution`. 

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

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


More information about the llvm-commits mailing list