MUNMAP(2) System Calls Manual MUNMAP(2)

munmapremove a mapping

#include <sys/mman.h>

munmap(void *addr, size_t len);

The () system call deletes the mappings for the specified address range, causing further references to addresses within the range to generate invalid memory references.

How munmap() handles a dirty page, depends on what type of memory is being unmapped:

If the memory is anonymous memory and if the last reference is going away, then the contents are discarded by definition of anonymous memory.
[System V Shared]
If the memory mapping was created using System V shared memory, then the contents persist until the System V memory region is destroyed or the system is rebooted.
[File mapping]
If the mapping maps data from a file (MAP_SHARED), then the memory will eventually be written back to disk if it's dirty. This will happen automatically at some point in the future (implementation dependent). Note: to force the memory to be written back to the disk, use msync(2).

If there are still other references to the memory when the munmap is done, then nothing is done to the memory itself and it may be swapped out if need be. The memory will continue to persist until the last reference goes away (except for System V shared memory in which case, see above).

Upon successful completion, munmap returns zero. Otherwise, a value of -1 is returned and errno is set to indicate the error.

munmap() will fail if:

The addr parameter was not page aligned (i.e., a multiple of the page size).
The len parameter was negative or zero.
Some part of the region being unmapped is not part of the currently valid address space.

#include <sys/types.h> #include <sys/mman.h>

The include file <sys/types.h> is necessary.

(caddr_t addr, size_t len);;

The type of addr has changed.

getpagesize(3), msync(2), munmap(2), mprotect(2), madvise(2), mincore(2), compat(5)

The munmap() function first appeared in 4.4BSD.

October 16, 2008 macOS 14.5