3

I'm studying operating systems at university and one of my tasks was find situation when malloc() doesn't cause mmap() system call.

I used strace linux utility to trace system calls, but in my situation I saw mmap() syscalls every time when malloc() was used.

Is malloc() always call mmap() or not?

Thanks

  • 2
    Note that you can simply get and read the source code of whatever memory allocator your system uses (or a custom one like jemalloc or tcmalloc). It is very instructive. Or you can look at [informal documentation](https://sourceware.org/glibc/wiki/MallocInternals) – Botje Nov 20 '20 at 09:01
  • malloc() usually calls a user-space sub-allocator for performance reasons. A syscall for more space can be made if the sub-allocator runs out. – Martin James Nov 20 '20 at 10:50
  • 2
    I'd bet $0.02 that the `malloc()` shipped with Microsoft compilers does not call `mmap()` at all :-) – Peter Nov 20 '20 at 11:33
  • ...or virtualAlloc(), or similar API :) – Martin James Nov 20 '20 at 14:43

2 Answers2

9

This is defined neither by C, C++ nor the POSIX standard.

Is malloc() always call mmap() or not?

Not necessarly. This depends on the malloc implementation, configuration and the size of the allocation and possibly other factors.

If using glibc:

Tunable: glibc.malloc.mmap_threshold

This tunable supersedes the MALLOC_MMAP_THRESHOLD_ environment variable and is identical in features.

When this tunable is set, all chunks larger than this value in bytes are allocated outside the normal heap, using the mmap system call. This way it is guaranteed that the memory for these chunks can be returned to the system on free. Note that requests smaller than this threshold might still be allocated via mmap.

If this tunable is not set, the default value is set to ‘131072’ bytes and the threshold is adjusted dynamically to suit the allocation patterns of the program. If the tunable is set, the dynamic adjustment is disabled and the value is set as static.

If not using glibc, then consult the documentation or source of the implementation that you use.

eerorika
  • 232,697
  • 12
  • 197
  • 326
0

I saw mmap() syscalls every time when malloc() was used.

This statement is similar in spirit to saying "There's no way to get to work today" - it only makes sense when lots of context is known. You'd have to disclose the exact benchmark you were using, glibc version, distro, etc. I'm pretty sure that if you're allocating lots of small objects (e.g. 16-32 bytes), you will not be seeing mmap() on every call.

Syscalls are performance hogs when compared to "limited" operations on data structures, so malloc() would perform very poorly if it really always invoked mmap(), no matter the circumstances. Sure, if you were always calling it like malloc(1024), then yes, it may end up mmap()-ing often.

And you'd also want to see what sort of mmap() arguments were passed.

So, all I see here is that your benchmark somehow is skewed against you :)

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313