2

Is memory malloc() through mmap() returned to OS immediately after calling free()?

CharlesLiuChina
  • 261
  • 1
  • 16
  • 2
    `mmap()` has nothing to do with `malloc()` and `free()`. What does it have to do with your question? – John Bollinger Dec 21 '16 at 06:59
  • Alex's answer [here](http://stackoverflow.com/questions/2215259/will-malloc-implementations-return-free-ed-memory-back-to-the-system) may be what you are looking for. – Gerrit0 Dec 21 '16 at 07:00
  • 1
    @JohnBollinger `malloc()` will call `mmap()` if request memory size is great than `M_MMAP_THRESHOLD`. – CharlesLiuChina Dec 21 '16 at 07:23
  • @CharlesLiuChina, when you pose a question that is specific to a particular implementation -- as apparently you have -- then it behooves you to tag it appropriately (i.e. [glibc]). Neither C nor POSIX specifies the behavior you describe. – John Bollinger Dec 21 '16 at 13:17

2 Answers2

2

Be aware that mmap is a system call which might be quite expensive. malloc implementations take care to avoid calling it too often, that is why they manage previously free-d zones to reuse them later (in further malloc-s) without any syscall. In practice, most malloc implementations manage differently big allocations (e.g. more than a megabyte), which are often mmap-ed at malloc and munmap-ed at free time.

mmap-ed at malloc, memory is immediately returned to the OS, when you do free (internal munmap).

You could study the source code of some malloc.

Sumit Gemini
  • 1,836
  • 1
  • 15
  • 19
  • I have read the source of `ptmalloc`, my project has a situation: each item is about `54K`, and 60000 items is loaded from database every 2 minutes. There are two points to do swapping for fresh items. Point `A` points to `54K * 60000 = about 3G` memory, `B` reload items from database, and take another `3G`, and then `A` swaps with `B` and `B` is `free`(d). But these `54K` items is `malloc`(ed) through `brk()` system call which won't be returned back to OS after `free`(d). So, I am going to decrease `M_MMAP_THRESHOLD` to make these `54K` items `free`(d) through `munmap`. – CharlesLiuChina Dec 21 '16 at 07:32
  • @CharlesLiuChina why do you want to use mmap-ed functionality. When a process needs memory, some room is created by moving the upper bound of the heap forward, using the brk() or sbrk() system calls. Because a system call is expensive in terms of CPU usage, a better strategy is to call brk() to grab a large chunk of memory and then split it as needed to get smaller chunks. This is exactly what malloc() does. It aggregates a lot of smaller malloc() requests into fewer large brk() calls. Doing so yields a significant performance improvement. – Sumit Gemini Dec 21 '16 at 07:40
  • I know that, but the OS needs that memory. I get a small RAM. – CharlesLiuChina Dec 21 '16 at 07:43
  • @CharlesLiuChina Okay, but there are two disadvantage also to use mmap, 1. deallocated space is not placed on the free list for reuse by later allocations; 2. memory may be wasted because mmap(2) allocations must be page-aligned. – Sumit Gemini Dec 21 '16 at 07:49
  • Yes, that's absolutely right. – CharlesLiuChina Dec 21 '16 at 07:52
2

According to http://man7.org/linux/man-pages/man3/mallopt.3.html

For allocations greater than or equal to the limit specified (in bytes) by M_MMAP_THRESHOLD that can't be satisfied from the free list, the memory-allocation functions employ mmap(2) instead of increasing the program break using sbrk(2).

Allocating memory using mmap(2) has the significant advantage that the allocated memory blocks can always be independently released back to the system. (By contrast, the heap can be trimmed only if memory is freed at the top end.) On the other hand, there are some disadvantages to the use of mmap(2): deallocated space is not placed on the free list for reuse by later allocations;

So the large allocations which should be done with help of mmap, has nothing to do with malloc's list of free or used blocks, and they're come back to system when freed.

e.jahandar
  • 1,715
  • 12
  • 30