user16310948
user16310948

Reputation:

Advantages of mmap() over sbrk()?

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

Answers (2)

eerorika
eerorika

Reputation: 238281

Advantages of mmap() over sbrk()?

  1. 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.

  2. brk/sbrk are not part of the POSIX standard and thus not portable.

    By contrast, mmap is standard and portable.

  3. 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.

  1. 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 freed. It would be a useful thing to do.

  1. "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

Barmar
Barmar

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

Related Questions