Reputation:
From my book:
Recall from our first discussion that modern dynamic memory managers not only use sbrk() but also mmap(). This process helps reduce the negative effects of memory fragmentation when large blocks of memory are freed but locked by smaller, more recently allocated blocks lying between them and the end of the allocated space. In this case, had the block been allocated with sbrk(), it would have probably remained unused by the system for some time (or at least most of it).
Can someone kindly explain how using mmap reduces the negative effects of memory fragmentation? The given example didn't make any sense to me and wasn't clear at all.
it would have probably remained unused by the system for some time
Why this claim was made, when we free it the system can use it later. Maybe the OS keeps list of freed blocks in heap to use them when possible instead of using more space in heap.
Please Relate to both questions.
Upvotes: 3
Views: 2312
Reputation: 238281
Advantages of mmap() over sbrk()?
brk
/sbrk
is LIFO. Let's say you increase the segment size by X number of bytes to make room for allocation A and X number of bytes to make allocation B, and then free A. You cannot reduce the allocated memory because B
is still allocated. And since the segment is shared across the entire program, if multiple parts of the program use it directly, you will have no way of knowing whether particular part is still in use or not. And if one part of the program (let's say malloc
) assumes entire control over the use of brk
/sbrk
, then calling them elsewhere will break the program.
By contrast, mmap
can be unmapped in any order and allocation by one part of the program doesn't conflict with other parts of the program.
brk
/sbrk
are not part of the POSIX standard and thus not portable.
By contrast, mmap
is standard and portable.
mmap
can also do things like map files into memory which is not possible using brk
/sbrk
.
it would have probably remained unused by the system for some time
Why this claim was made
See 1.
Maybe the OS keeps list of freed block
There are no "blocks". There is one (virtual) block called the data segment. brk
/sbrk
sets the size of that block.
But doesn't mmap allocate on heap
No. "Heap" is at the end of the data segment and heap is what grows using brk
/sbrk
. mmap
does not allocate in the area of memory that has been allocated using brk
/sbrk
.
mmap
creates a new segment elsewhere in the address space.
- does malloc actually save the free blocks that were allocated with sbrk for later usage?
If it is allocated using brk
/sbrk
in the first place, and if malloc
hasn't reduced the size of the "heap" (in case that was possible), then malloc
may reuse a free "slot" that has been previously free
d. It would be a useful thing to do.
- "then calling them elsewhere will break the program." can you give an example
malloc(42);
sbrk(42);
malloc(42); // maybe kaboom, who knows?
In conclusion: Just don't use brk
/sbrk
to set the segment size. Perhaps there's little reason to use (anonymous) mmap
either. Use malloc
in C.
Upvotes: 4
Reputation: 780655
When sbrk()
is used, the heap is just one, large block of memory. If your pattern of allocating and freeing doesn't leave large, contiguous blocks of memory, every large allocation will need to grow the heap. This can result in inefficient memory use, because of all the unused gaps that are left in the heap.
With mmap()
, you can have a bunch of independent blocks of mapped memory. So you could use the sbrk()
heap for your small allocations, which can be packed neatly, and use mmap()
for large allocations. When you're done with one of these large blocks, you can just remove the entire mapping.
Upvotes: 3