This reduces the size of PageMap and we are more likely to use the
static local buffer. Note that now this is only supported for single
region case, i.e. on SizeClassAllocator64. For SizeClassAllocator32,
it needs a different way to save the PageMap.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Is there any performance penalty of going from a single pass to two pass approach? Is the number of blocks usually small so there isn't much of an issue?
compiler-rt/lib/scudo/standalone/primary64.h | ||
---|---|---|
804 | Might be better worded as: visiting BlockGroups twice. | |
813 | of the number | |
821 | Is there a reason you are using a comma, rather than making this two statements? It's a bit odd to see this construct, but it might just be me. | |
885 | I think you mean that the Next pointer can be modified. Either that or maybe use destructive to indicate the Next pointer could be changed. | |
888 | After this loop, Prev is still pointing to the current previous block instead of Cur. Is this intended? | |
908 | Should this be roundUpSlow? I assume from the name that his is a slower way of doing the round up, but I might be incorrect. | |
910 | As with the other change, making all of these Beg suffixes be Base instead make the code easier to read. | |
compiler-rt/lib/scudo/standalone/tests/release_test.cpp | ||
443 | logic of how |
Address review comment
compiler-rt/lib/scudo/standalone/primary64.h | ||
---|---|---|
821 | TBH, I simply wanted to make the induction variables updating compact (here and below). Changed them two separate lines instead. | |
888 | Yes, we extract the current one and the Cur->Next will be the next of Prev | |
908 | The BlockSize may not always be power-of-2 so we need to use the slower version here. | |
910 | Done. BTW, I'm considering to also change the RegionBeg to RegionBase in another CL |
The preliminary measurement showed that the cost of two pass was neglectable. I will bring some numbers later.
One last question about a bit of code.
compiler-rt/lib/scudo/standalone/primary64.h | ||
---|---|---|
888 | But BG has already been set to BG->Next. So if you hit this part of the loop twice in a row, the second time: Prev is the same as in the previous loop Did you mean BG->Next will be the next batch of Prev? At the very least, I think a comment would help here since this is kind of confusing and look wrong. |
- Add more comments on BG extraction
- Fix a bug in releaseToOs and add more tests
compiler-rt/lib/scudo/standalone/primary64.h | ||
---|---|---|
888 | I guess the confusion comes from how we update Prev. Prev will be pointed to BG->Next by FreeList::extract() so the relation between Prev and BG->Next is updated. Added more comments. |
Add a performance number: The time spent in extracting/merging BatchGroup
02-21 21:04:56.996 515 515 I scudo : -- Average Operation Time -- -- Name (# of Calls) -- 02-21 21:04:56.996 515 515 I scudo : 68.3(ns) Extract/MergeBlock (7700)
For relands, we usually use Reland $original_subject instead of Revert Revert $original_subject :)
Likewise, one Revert is sufficient, no need for Revert Revert Revert $original_subject (3)
I usually use Revert Dxxxx $original_subject instead of Revert Dxxxx $original_subject so that the revert commit is associated with this page. You can see the commit in "Commits" in the "Details" section.
Might be better worded as:
visiting BlockGroups twice.