how does malloc/free work?

Here is the answer I got from Internet.

Here's a simple, vague answer:

Your process has a region of memory, from address x to address y, called the heap. All your malloc'd data lives in this area. malloc() keeps some data structure, let's say a list, of all the free chunks of space in the heap. When you call malloc, it looks through the list for a chunk that's big enough for you, returns a pointer to it, and records the fact that it's not free any more as well as how big it is. When you call free() with the same pointer, free() looks up how big that chunk is and adds it back into the list of free chunks(). If you call malloc() and it can't find any large enough chunk in the heap, it uses the brk() syscall to grow the heap, i.e. increase address y and cause all the addresses between the old y and the new y to be valid memory.
brk() must be a syscall; there is no way to do the same thing entirely from userspace.

brk() can be used to shrink the heap as well as grow it. When this happens, y decreases. You can have situations where most of the heap is free, but it can't be shrunk because some chunk at the top of it (near y) isn't free; in this case, the process hogs a lot of memory it doesn't really need. Alternatively, the malloc and free could just decide to keep the heap a certain size and not make it any smaller, on the theory that brk() can be slow and you're likely to need the memory again. I don't know how they tend to be implemented in practice.

You should look into some malloc debugging tools if you're trying to hunt down a memory leak; I've used dmalloc, I'm sure there are others too.

btw, it should be noted that what I've described in my other post doesn't have to be *the* way it works everywhere, but it's true for unixy systems at a minimum.

http://www.linuxquestions.org/questions/programming-9/how-does-malloc-and-free-functions-work-262165/


The "break"--the address manipulated by brk and sbrk--is the dotted line at the top of the heap. The documentation you've read describes this as the end of the "data segment" because in traditional (pre-shared-libraries, pre-mmap) Unix the data segment was continuous with the heap; before program start, the kernel would load the "text" and "data" blocks into RAM starting at address zero (actually a little above address zero, so that the NULL pointer genuinely didn't point to anything) and set the break address to the end of the data segment. The first call to malloc would then use sbrk to move the break up and create the heap in between the top of the data segment and the new, higher break address, as shown in the diagram, and subsequent use of malloc would use it to make the heap bigger as necessary.

http://stackoverflow.com/questions/6988487/what-does-brk-system-call-do

When user space applications call malloc(), that call isn't implemented in the kernel. Instead, it's a library call (implemented glibc or similar).

The short version is that the malloc implementation in glibc either obtains memory from the brk()/sbrk() system call or anonymous memory via mmap(). This gives glibc a big contiguous (regarding virtual memory addresses) chunk of memory, which the malloc implementation further slices and dices in smaller chunks and hands out to your application.

Here's a small malloc implementation that'll give you the idea, along with many, many links.

Note that nothing cares about physical memory yet -- that's handled by the kernel virtual memory system when the process data segment is altered via brk()/sbrk() or mmap(), and when the memory is referenced (by a read or write to the memory).

To summarize:

1. malloc() will search its managed pieces of memory to see if there's a piece of unused memory that satisfy the allocation requirements.
2. Failing that, malloc() will try to extend the process data segment(via sbrk()/brk() or in some cases mmap()). sbrk() ends up in the kernel.
3. The brk()/sbrk() calls in the kernel adjust some of the offsets in the struct mm_struct of the process, so the process data segment will be larger. At first, there will be no physical memory mapped to the additional virtual addresses which extending the data segment gave.
4. When that unmapped memory is first touched (likely a read/write by the malloc implementation) a fault handler will kick in and trap down to the kernel, where the kernel will assign physical memory to the unmapped memory.

http://stackoverflow.com/questions/5716100/what-happens-in-the-kernel-during-malloc