Is there any chance of an address returned by mmap(2) clashing with the heap?

Question

If I allocate some pages using mmap(2), without providing an address hint, and later allocate some memory using malloc(3) / calloc(3), is there a chance that malloc calls sbrk(2) and grows the heap in a way that it overlaps onto the address returned by my earlier call to mmap or is mmap always guaranteed to return an address far away from the heap or stack?

Answer 1

No, there is no risk of a clash, not in linux and probably not in any implementation using paging -- and I doubt there would be an mmap() on systems without paging. I can't tell you now (because I just don't know it) which virtual addresses mmap() uses: probably indeed far enough from the heap. For the physical memory: sbrk() will sooner or later provoke a page fault and of course, your OS will take care to map you a page that isn't in use. mmap() works on whole pages anyways...

edit as rodrigo points out correctly, big requests to malloc() are served using mmap() anyways. So for the small requests being served using sbrk(), you don't have to expect too many pagefaults.

Answer 2

No, you will not have overlaps.

That does not mean that they will be far away, they may be just next to the other. But if you respect the limits of the allocated memory all will be fine.

Note that the glib implementation of malloc() will use anonymous mmap() calls to satisfy requests for big chunks of memory.