On POSIX, MemoryMappedFile attempts to physically allocate disk blocks for the underlying file when arranging for writeable memory-mapped regions backed by files on disk. This is because, unlike traditional write()-based operations that fail with an error code on write error, failed writes to memory-mapped files result in a signal (SIGBUS) which is difficult to cope with. The easiest way for this to happen is when using memory-mapped I/O to write to a sparse file residing on a sparse filesystem. If a write would force new block to be physically allocated and there aren’t any free blocks, the operation will raise a signal.

https://chromium.googlesource.com/chromium/src/+/0413fd9f7c660ba7504dade7bb838862f138348e/base/files/memory_mapped_file_posix.cc#104

This was done in bug 715523, https://codereview.chromium.org/2860943005, e41b5ce8a877875575ad0c370bd4bdc8593113b2. macOS was excluded because its default (and only truly viable) filesystem, HFS+, doesn’t support sparse files. All files always have all blocks physically allocated.

In 10.13, Apple is declaring their new filesystem, APFS, ready for desktop use, and is making it the default. APFS does support sparse files.

The idea that sparse files can’t be encountered on macOS is no longer true. The POSIX MemoryMappedFile now needs to take this into account.

Unfortunately, the best way to implement this, posix_fallocate(), doesn’t exist on macOS. I filed https://openradar.appspot.com/32720223 requesting it.

In the mean time, we should enable the “need to worry about sparse files, but there’s no posix_fallocate()” fallback that we currently use for Android with API < 21, and for that matter, that we fall back to when posix_fallocate() fails. This mechanism is racy and could cause data loss, but shouldn’t be a practical problem in its usage in MemoryMappedFile. It’s also potentially slower than a posix_fallocate() system call would be, but if the system doesn’t provide it, then our hands are tied.