[scudo] Finer lock granularity in Region of SizeClassAllocator64 In this CL, we introduce two new locks, MMLock for MemMap operations and FLLock for freelist operations. MMLock will be used when we want to manipulate pages. For example, mapping more pages through populateFreeList() and releaseToOSMaybe(). FLLock will be used when we want to access the freelist. For example, pushBlocks() and popBatch(). With the new locks, they increase the parallelism of the operations mentioned above. For example, populateFreeList() won't block the pushBlocks() when it's still doing the system call for more pages. We also enforce lock hierarchy to avoid deadlock, MMLock is required to be held before FLLock if you have to lock both of them. We don't store the lock owner, therefore, we rely static thread-safey annotation to detect any violation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
compiler-rt/lib/scudo/standalone/primary64.h | ||
---|---|---|
499–501 | You're right. I forgot it's passed by reference in shuffle(). Will fix it in later CL |
compiler-rt/lib/scudo/standalone/primary64.h | ||
---|---|---|
168 | to call | |
171 | Use a condition | |
185 | gets | |
189 | Since the same locks aren't being held, I'm guessing you still want to do the stats printing after the loop to avoid holding MMLock. If so, you should probably put a comment here about that. | |
223 | using a condition | |
228 | Is there a reason you are using a variable here? It looks like the if statement below is the only time NeedToRefill is used. |
Address review comment
compiler-rt/lib/scudo/standalone/primary64.h | ||
---|---|---|
228 | I hope this variable will give the idea of why we check Size == 1U and that is a little bit unclear at the first glance. In the future change D152419, we add one more condition here so I think it may be better not to squeeze them in the predicate. |
to call