Re: Memory fragmentation?

On Nov 14, 12:38 pm, "[email protected]"
<[email protected]> wrote:
> I just had a thought about the fragmentation problem.  That problem is
> often best described as "too many small allocations."  But the real
> danger seems to be that we're mixing tons of small allocations and
> several large ones.  For example, if you allocate 128 bytes, allocate
> 100k and then allocate another 128 bytes after that, the entire 100k
> is pinned, leaving large gaps.
>
> Given a stat that I overheard the other day (something like "98% of
> our allocations are under 128 bytes" or equally crazy) wouldn't it
> make sense to look at trying to move the big allocations to another
> heap and/or use anonymous mmap pages where it makes sense?  That way
> at least the huge allocations wouldn't mix with the small ones and
> those pages wouldn't be pinned with such large gaps.  It does let us
> return more memory to the operating system.  Also, from the standpoint
> of identifying where most of those allocations take place I'm sure
> it's a much more doable task.  I'll bet that the call sites that
> generate huge allocations are much easier to find and much fewer in
> number.
>
> That's not to say that fixing some of the high-value targets that are
> responsible for a lot of the small allocations aren't important.  But
> it seems like we can hit the top level number pretty hard and really
> make a difference in what we return to the OS if we block off the big
> allocations to a place where they are more likely to be returned.
>
> Thoughts?  Too much overhead?  Too much manual work?  Anonymous
> regions will still be mixed into the same heap address space?  (not on
> Linux, anyway, I don't know about mac + windows.)

I don't think this would be the best general purpose solution.  Most
large allocations (think image size allocations) end up outside of the
main heap area by most allocators already.  We can do something like
this in smaller areas, but I think us getting a better understanding
of lifetimes of grouped objects that we can pool together and free
together will result in much bigger wins.  We also need to simply
reduce the number of allocations.