confusion about brk and mmap in expand_heap in malloc implementation

confusion about brk and mmap in expand_heap in malloc implementation

[Yuxin Ren]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Hi,

I found in the __expand_heap function used by malloc, if brk fails, it will
use mmap to get a memory area.
I think in this case, this area should be returned back to system via
munmap.
But in my test, when I free such area, I found it is still passed to
madvise, not munmap.

How do we track if an area is expanded by brk or mmap?
And when we free an area, how do we decide to use munmap or madvise?

Thanks a lot.
Yuxin

[-- Attachment #2: Type: text/html, Size: 1584 bytes --]

Re: confusion about brk and mmap in expand_heap in malloc implementation

[Rich Felker]

On Thu, Sep 10, 2015 at 02:58:33PM -0400, Yuxin Ren wrote:
> Hi,
> 
> I found in the __expand_heap function used by malloc, if brk fails, it will
> use mmap to get a memory area.
> I think in this case, this area should be returned back to system via
> munmap.
> But in my test, when I free such area, I found it is still passed to
> madvise, not munmap.
> 
> How do we track if an area is expanded by brk or mmap?
> And when we free an area, how do we decide to use munmap or madvise?

I think you're starting from some mistaken assumptions. The managed
heap for small allocations (under a few hundred kb) is permanent for
the lifetime of the process once it's allocated, whether it comes from
brk or mmap. The only difference between the two approaches of
obtaining memory is that brk is faster and makes it possible to obtain
a contiguous range gradually rather than having to request large
amounts at a time to ensure contiguity.

Either way, what madvise does is free up the _physical_ memory backing
large contiguous free areas on the heap. No attempt is made to free
virtual address space (this would be a very bad idea; it could lead to
heavy fragmentation) or commit charge. I have some ideas for freeing
commit charge in the future, which may be desirable.

Rich