c++ - What does it mean that mmap doesn't work 'when a large chunk becomes “locked” in between smaller ones'?

Question

I was reading the GNU C library document for the GNU memory allocator. https://www.gnu.org/software/libc/manual/html_node/The-GNU-Allocator.html

In the paragraph about using mmap to allocate big chunks of memory, it says

The other way of memory allocation is for very large blocks, i.e. much larger than a page. These requests are allocated with mmap (anonymous or via /dev/zero; see Memory-mapped I/O)). This has the great advantage that these chunks are returned to the system immediately when they are freed.

Therefore, it cannot happen that a large chunk becomes “locked” in between smaller ones and even after calling free wastes memory.

From what I've understood mmap seems to be a function where I can assign a contiguous memory space to a file (or vice versa?).

So I don't understand this part, can't the memory chunk be freed even though it is between smaller ones? And then we can use it for mmap?

What kind of situation would this be in a real program?

question from:https://stackoverflow.com/questions/65661972/what-does-it-mean-that-mmap-doesnt-work-when-a-large-chunk-becomes-locked-in

Answer 1

Consider a long-running logical function of a program that allocates lots and lots of memory. And at the same time that logical function is running, other bits of code allocate very small chunks of memory.

Later on, that long-running function may finish and the massive amount of memory it allocated is all freed. But lots of small bits allocated by other logical functions of the program are still holding memory.

You may have a case where the program requested a huge amount of memory from the operating system and almost all of that memory is free, but nevertheless, no memory can be returned to the operating system by the program's allocator because every chunk it allocated from the system still has a tiny piece in use. This is called "memory fragmentation".