On Mon, Aug 31, 2020 at 2:41 AM Otto Moerbeek <[email protected]> wrote:
> Hi, > > A question from Theo made me think about realloc and come up with a > particular bad case for performance. I do not know if it happens in > practice, but it was easy to create a test program to hit the case. > > We're talking allocation >= a page here. Smaller allocation follow > different rules. > > If an allocation is grown by realloc, I first tries to extend the > allocation by mapping pages next to the existing allocation. Since > the location of pages is randomized, chanches are high that next to an > allocation there are unmapped pages so the grow will work out. > > If realloc needs to shrink the allocation it puts the high pages no > longer needed in the malloc cache. There they can be re-used by other > allocations. But if that happens, next a grow of first allocation will > fail: the pages are already mapped. So realloc needs to do a new > allocation followed by a copy and a cleanup of the original. > > So this strategy of a shrinking realloc to of put unneeded pages into > the cache can work against us, plus it has the consequence that use of > realloc leads to allocations close to each other: no free guard pages. > If I am interpreting this correctly, realloc could be used to groom/shape the heap such that future allocations are less random and more predictable? --david
