Re: Memory fragmentation?

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.)