I am confused by the differences between "brk()" and "mmap()". My understanding is that both are used by malloc() to increase the boundary ot heap.
Then why there are 2 different ways?
http://lwn.net/images/ns/kernel/mmap1.png
I am confused by the differences between "brk()" and "mmap()". My understanding is that both are used by malloc() to increase the boundary ot heap.
Then why there are 2 different ways?
http://lwn.net/images/ns/kernel/mmap1.png
brk() is a traditional way of allocating memory in UNIX -- it just expands the data area by a given amount. mmap() allows you to allocate independent regions of memory without being restricted to a single contiguous chunk of virtual address space.Originally Posted by meili100
malloc() uses the data space for "small" allocations and mmap() for "big" ones, for a number of reasons, including reducing memory fragmentation. It's just an implementation detail you shouldn't have to worry about.
Thank you. I can understand brk(), but what if brk() reaches the boundary of the top of a heap (4G memory)?
Also, how does mmap() allocate memory by mapping? What is the source of the mapped memory? My friend told me that mmap() maps kernal memory to user, but I really doubt him. Is he right?
Moved to Linux Programming since that is the most related forum.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Both brk() and mmap() cause pages to be mapped into the process's address space. mmap() can be used to map pages of a file into memory, but it can also be used only to map pages, i.e., allocate memory. brk() is just a specific interface to the VM subsystem which maps pages at a specific location (top of heap). mmap() on the other hand lets you map any page (mostly) anywhere you want.
brk() could be implemented with mmap(), but not vice versa.
As for where the pages come from, that's up to the kernel. The process can decide which virtual address it wants mapped -- the kernel is responsible for allocating a physical page and mapping it where the process has requested.
Why don't we use mmap() in the first place? We know that brk() has a disadvantage that: if the block at the top of heap is not freed, the heap size can not be reduced, even if the top block is only ONE BYTE.
mmap() is better than brk(). So why don't we use mmap()?
mmap() is no better unless you really want to cater for the rather special case that you want to reduce the heap when it's got most of it's memory freed but a small section at the top end of the heap is occupied. The brk() model is perfectly fine for most purposes, as the heap will normally (in typical applications) grow to a certain size, and then either fluctuate a little bit up and down from that size, or grow and then shrink again. In the normal case for grow and shrink, it's mainly "newest allocations" being deallocated.
Also, if there are large "holes" in the heap, those areas are good candidates for swapping out to disk, as they will not be touched. So whilst it's taking up VIRTUAL memory space, it's not going to cause much of a problem in the physical memory (assuming there's a squeeze in the first place of course).
Oh, and by the way, memory allocated via brk() is most likely not committed until it's being written to, so if you allocate a large chunk of memoyr (using malloc() or close relatives), not all that memory will be used in physical memory until it's been "used" (read or written).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
As matsp said, things get swapped out and don't cause a problem anyway. And if you really wanted to release memory inside the heap, nothing is stopping you from munmap()'ing it (aside from probably confusing the hell out of malloc()).
brk() is just an older, traditional way of obtaining more pages from the OS. I don't really think either one is "better" than the other.
