I read it to mean mmap is irreplaceable. There is no other sophisticated dance of system calls or userspace trickery that can achieve what mmap can achieve. She's saying that everything up and down the stack, including high level libraries, do just call mmap, because there would be no DIY alternative with similar cost-benefit.

Except it’s not irreplaceable, at least on Linux. userfaultfd allows you to define custom page fault handling. With it, you can even do crazy things like “mmap” a remote resource by making HTTP range requests on a read fault.

You’re right. Irreplaceable was a stronger way of putting it than the original, I think, so that’s more my mistake than hers, and I think the contrast with userspace stands.

mmap sits at this lovely intersection between virtual memory and the disk, and it’s been around for a long time. By now there are other means of playing within that nice intersection, but mmap is the pop classic.

Is there anything like that on Windows?

Windows has vectored exception handlers, which are a bit like UNIX signal handlers but much more sanely designed. You can use that to redirect control flow when a page fault occurs, and you can check the faulting address in your handler to scope it to a particular region of memory.

Yes, it's how JITs like Java work. Though I don't specifically know what the Windows API is.

This has nothing to do with JITs. JITs just have a stub trampoline. Some garbage collectors do have page tracking though.

It might be the non-obvious problem with mmap : failures are surfaced through signals. So, a failure signal handler may run at any time. Your program needs to be resilient to this, and it's not trivial to do so. It's not a local change to one class.

I'm not sure what really needs abstracting about it other than tuning stuff for a given kernel/system.

It's already extremely high level from a certain perspective :)

Boost.interprocess is an example of an abstraction over mmap which solves some of the things the blog post mentions. It abstracts away the difference between mmap() and CreateViewOfFile(), and gives you smart pointers and container types which are close to being drop-in replacements for std::vector and std::map that can be stored in a memory-mapped file.

Someone has to own the memory region and know it gets munmap()ed not free()d. (deleted?)

If you send it over IPC it's nice to keep it mmapped instead of accidentally copying it too.