issue-368: unmap free spans and retry before growing heap

Because unmapped spans are not coalesced with normal spans it's
possible that we indeed have a large enough free span, but we fail to
see that because we always consider unmapped and normal spans
separately. That behavior is more likely for larger spans.

In order to protect programs that grow heap frequently and by small
amounts from much more frequent minor page faults, there's limit of
running that force pages unmap path once per 128 megs of heap growth.



git-svn-id: http://gperftools.googlecode.com/svn/trunk@210 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
issue-{368,443}: allocate metadata in big batches

It uses same approach as PageHeapAllocator. Namely allocates big chunk
which is then used to satisfy smaller allocations.

In issue-443 gradual heap grows causes old code that allocates
metadata in smaller pieces and thus more frequently to fragment the
heap. It's also causing most of 368 heap fragmentation too.

New code allocates 8 megs of address space at once for metadata
allocations. Most OSes will allocate actual memory only when
corresponding pages are touched. Thus this change should not cause
increased memory usage.

I've also made sure metadata is always properly aligned in case we
ever allocate something that breaks natural alignment. E.g. strings.



git-svn-id: http://gperftools.googlecode.com/svn/trunk@211 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
issue-368: test that we don't fragment large spans too badly

This adds unit test that does essentially same things as code to
reproduce bug in
https://code.google.com/p/gperftools/issues/detail?id=368




git-svn-id: http://gperftools.googlecode.com/svn/trunk@212 6b5cf1ce-ec42-a296-1ba9-69fdba395a50