1) Yes, for OSes that support memory-mapped files. The OS simply allocates a region of the virtual address space for the file, and sets up its paging algorithms so that,
- when a page is accessed but is not in RAM, it is loaded in RAM
- when there's little RAM left, some memory-mapped pages can be saved to disk and freed (they can be reloaded later on, if needed, from disk)
This is very similar to what happens with swapping.
2) On 64 bit systems, I'd say that virtual address space is a non-issue. Even with files as ridiculously large as 1PB=1024TB each, you'd have to map 16000+ of them to exhaust the space. Even if some address space is reserved by the OS, this limitation is irrelevant until we can store petabytes very easily.
On 32-bit systems, yes, that can be an issue.
For a possible reason: read-only memory-mapped segments are cheap. The OS can unload their pages when memory becomes too tight, without accessing the disk. If the process used regular memory the access would be less efficient, unless the process implements some memory-management itself. The process is simpler to design since it can exploit the OS for making access efficient, and pretend a large file was fully loaded in RAM, roughly.
Read-write memory-mapped segments are less useful, in my opinion, but those are also simple to use by the process.
3) the file is read from (and written to, if the mapped segment isn't read-only) disk. But this is done by the OS, in its paging routines, not by the process.
