Memory-Mapped File
Also known as: mmap, memory mapped io, memory mapped file
A memory-mapped file maps a file's contents directly into a process's virtual address space, so the OS pages data in on demand instead of copying it with explicit read/write calls. It lets apps treat a large file like an in-memory array.
- Created with mmap() on iOS/Android/macOS/Linux and MapViewOfFile() on Windows.
- Data loads lazily per page on first access via page faults, not all at once.
- Clean file-backed pages can be reclaimed by the OS without writing to disk.
How memory mapping works
When a program calls mmap() (POSIX) or MapViewOfFile() (Windows), the OS sets up page-table entries that point a range of the process's virtual memory at the file on disk. No data is actually loaded yet. The first time the program touches a mapped page, the CPU triggers a page fault and the kernel reads just that 4 KB page (or a small cluster) from storage.
Because the page cache backs the mapping, reads and writes go through the same cached pages the OS already uses for normal file I/O. Modified pages are marked dirty and written back lazily by the kernel, or immediately if the program calls msync(). This avoids the extra buffer copy that read()/write() require, which is why mmap is often faster for random access over large files.
Why apps use it for media and databases
Media-heavy and database code maps files because it can seek anywhere in a multi-gigabyte file while only the touched regions consume RAM. SQLite can use memory-mapped I/O for its database file, and many image/video libraries map large assets so decoders read frames without loading the whole file. On Android, the runtime maps app code and resources (such as the .dex/.oat and .apk) so the OS can share read-only pages across processes and reclaim them under pressure.
The tradeoff is that mapped pages count against the process and the system page cache, and a mapping that touches every page of a huge file can spike memory use. On mobile, the kernel can evict clean (file-backed) mapped pages cheaply when memory is tight, which is one reason file-backed memory is treated differently from anonymous (heap) memory in low-memory handling.