On Mon, Aug 31, 2020 at 08:28:25AM -0400, David Higgs wrote:
> 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
In a way yes, but that's a consequence of caching pages: new
allocations will come from the cache if possible. But with this diff
there are less possibilities. Also note that malloc option S disables
the cache.
-Otto
