What if I allocate memory using mmap instead of malloc?

Question

What are the disadvantages of allocating memory using mmap (with MAP_PRIVATE and MAP_ANONYMOUS) than using malloc? For data in function scope, I would use stack memory anyway and therefore not malloc.

One disadvantage that comes to mind is for dynamic data structures such as trees and linked lists, where you frequently require to allocate and deallocate small chunks of data. Using mmap there would be expensive for two reasons, one for allocating at granularity of 4096 bytes and the other for requiring to make a system call.

But in other scenarios, do you think malloc is better than mmap? Secondly, am I overestimating disadvantage of mmap for dynamic data structures?

One advantage of mmap over malloc I can think of is that memory is immediately returned to the OS, when you do munmap, whereas with malloc/free, I guess memory uptil the data segment break point is never returned, but kept for reusage.

Solution 1

Yes, malloc is better than mmap. It's much easier to use, much more fine-grained and much more portable. In the end, it will call mmap anyway.

If you start doing everyday memory management with mmap, you'll want to implement some way of parceling it out in smaller chunks than pages and you will end up reimplementing malloc -- in a suboptimal way, probably.

Solution 2

First off, mmap() is a platform specific construct, so if you plan on writing portable C, it's already out.

Second, malloc() is essentially implemented in terms of mmap(), but it's a sort of intelligent library wrapper around the system call: it will request new memory from the system when needed, but until then it will pick a piece of memory in an area that's already committed to the process.

Therefore, if you want to do ordinary dynamic memory allocation, use malloc(), end of story. Use of mmap() for memory allocation should be reserved for special situations (e.g. if you actually want a whole page for yourself, aligned at the page boundary), and always abstracted into a single piece of library code so that others may easily understand what you're doing.

Solution 3

One feature that mmap has that malloc doesn't, is mmap allows you to allocate using Huge Pages (flag argument has MAP_HUGETLB set), while malloc doesn't have that option.

Comments

[Macmade]

malloc will call mmap for you, if necessary... Just stick to malloc.

[Oliver Charlesworth]

Another disadvantage is that if you litter your code with calls to mmap, it becomes less portable.

[Ed Heal]

And why make life more complicated than it needs to be?

[osgx]

Malloc is better for small allocations and for high rate of malloc/free of not-so-huge sizes. This is because malloc can ask a huge pool for small sized requests and do small allocations/deallocations from it, without any mmap/munmap.

[Zan Lynx]

The only place I can think this would be really useful is implementing memory pools. With malloc you leave yourself open to fragmentation. With mmap you could return the entire pool to the OS without leaving a tiny string fragment (for example) sitting at the end of the address space.

[jleahy]

Even if you do want a whole page for yourself then it's probably better to use posix_memalign, it'll be quicker to allocate, quicker to free and will free the kernel from the hassle of tracking another vma. Really the only reason to use mmap is if you want to map a file descriptor into memory (the most common use) or are implementing a memory allocator (and even then there are good reasons to prefer sbrk).

[Jingguo Yao]

Great in-depth answer since it mentions that malloc calls mmap.

[Bogi]

And also it allows you to ask the operating system to allocate all the memory upfront, in order to avoid page faults (used for low-latency programming).