This article introduces the main application scenarios of Mmap on iOS, the most important of which is that it can be used to solve OOM problems.

For more content and technical exchanges, please pay attention to the wechat official number: Code Worker notes

1. Basic concepts of MMAP

Mmap: File mapping, used to map files or devices into a virtual address space so that users can manipulate files or devices as if they were memory addresses.

Ii. Attribute classification of MMAP:

  • Depending on whether mmap is file-based:

    • File-based mapping:
      • By mapping files on the hard disk to a segment of the process’s virtual address space, developers can read and write files on the hard disk as if they were reading or writing to memory.
    • Non-file-based mapping (MAP_ANONYMOUS)
      • Create a space in the virtual address space, similarmalloc

  • Depending on whether changes to MMAP data are immediately visible to other processes:

    • MAP_SHARED:
      • File-based: Other processes that map the same file can see the changes made to the file by this process
      • Not file-based: The writing process needs to call msync for other processes to see the changes
    • MAP_PRIVATE: Changes are visible only to this process

Iii. Main Features and Usage scenarios of MMAP

  • Use Mmap to improve file read and write efficiency

    Mmap allows developers to read and write a file as if it were contiguous memory. By default, the operating system’s paging function is used to lazily load related pages on demand. The file data on the hard disk (actually the data in the Page cache) is mapped to Page entries on a Page basis, which improves the read and write efficiency.

  • Use Mmap to improve file writing reliability

    In iOS, there are many different ways to write files, such as fopen/fwrite, open/write, mmap, etc. Either way, after a write operation is invoked, the data written is not solidified directly to a file on the hard disk, but is cached by the operating system or standard libraries (to improve I/O efficiency). In mmap mode, if the user process crashes after a write, the operating system ensures that the cached data is flushed correctly to the hard disk. In similar cases, write/fwrite data may be lost (for details, see Client Development Basics – Avoiding “potholes” in Writing files).

  • Use MMap to fix App Memory Quota (OOM)

    In the iOS operating system, if an application process occupies too much Memory and exceeds the preset quota, the system will generate OOM (Out Of Memory). In this case, the system will kill the process, causing the user’s view to blink back. The amount of memory an application can use is determined by a number of factors, including the following:

    • Quota manually set by the operating system
      • IOS has different restrictions based on different models, operating systems, and application types
      • Like third-party input methods (Keyboard Extension) process, the latest iOS system limits it to use a maximum of 80MB of memory, exceeding this limit will be killed by the operating system
    • Physical memory limit of the device
      • The device has a certain amount of physical memory. For example, the iPhone 6 has 1 GIGAByte of memory, which means that all processes running on the phone (including user processes and the operating system) have a maximum of 1 gigabyte of physical memory available.
      • Because iOS does not have a swap area, the operating system can only kill user processes to release physical memory resources when they are insufficient
        • Background processes are killed first, and foreground processes are killed only if the requirements are not met

    The data stored in the physical memory occupied by each process running on the device can be divided into two types according to whether it can be safely discarded:

    • Safe to discard (i.e. can be read back from the file without error after being discarded)
    • Non-discardable (that is, the data is not directly mapped to a file in the operating system)

    Data that can be safely discarded, even if it currently occupies physical memory, can be removed from physical memory at any time because it can be read back from a file on demand by the operating system. Therefore, it can be considered that this data does not occupy the physical memory quota.

    Non-throwable data exists only in physical memory, with no files bound to it. So the physical memory it sits in is occupied until the application explicitly tells the operating system to free it (for example, by calling the free method), and any early release may result in data loss.

    There is also a special case: compressed memory, which means that the operating system may choose to compress some dirty memory under certain conditions, so as to reduce the size of the physical memory occupied by the process to access it before decompressing. This type of memory is also not disposable, as it always occupies the compressed size of physical memory.

    If a file-based MAP_SHARED type of Mmap is used, the application’s read and write operations at the corresponding virtual memory address are mapped directly to the file block, and the physical memory used by the application is deemed safe to be discarded by the operating system without occupying the physical memory quota (except for page table entries).