Why virtual memory exists
“Why does virtual memory exist? List the problems we would have without it, and then the costs it introduces.”
What this tests
- Virtual memory as the answer to several constraints: isolation, relocation, sharing, lazy allocation
- The mechanism: pages, page tables, the MMU, faults
- The costs: translation, page-table memory, faults, and the TLB as the mitigation
- RSS vs virtual size and overcommit as production consequences
Answers by level
Read the beginner answer first and notice what is missing.
Without it, every process would address physical RAM directly. Then: a bug in one program could overwrite another’s memory or the kernel’s (no isolation); every program would have to be linked for the exact physical addresses it will get (no relocation); two programs could not share one copy of libc; a program needing 1 GB would need 1 GB of *contiguous* free RAM (fragmentation); and a program could not ask for memory it might not use. Virtual memory fixes all of these with one indirection: each process sees its own private address space, and the hardware translates (Why Virtual Memory?).
The mechanism is paging: the address space is split into fixed pages (4 KB on x86-64 and most Linux builds; 16 KB on Apple silicon), physical memory into frames of the same size, and a per-process page table maps page → frame with permission bits (read, write, execute, user/kernel). The MMU consults it on every access. A page with no valid mapping raises a page fault, which is not an error but the kernel’s hook: it can lazily allocate a zero page, load a file page, copy a copy-on-write page, or — if the access really is invalid — deliver SIGSEGV (Paging, Page Faults).
The costs: every memory access now needs a translation, which would double or quadruple memory traffic if done by walking the table each time — so the CPU caches translations in the TLB, and TLB misses are a real cost for large working sets (The TLB). Page tables themselves consume memory (a 4-level x86-64 table is a few MB per GB of mapped memory). And faults, when they hit disk, cost ~100 µs on SSD — the "swap" case beginners lead with is the pathological end of a spectrum whose normal end is free.
Production consequences follow directly. Virtual size (VSZ) is mostly reservations and means little; RSS is the pages actually resident. malloc(1 GB) succeeds and costs nothing until touched (Linux overcommit), so a process can be killed by the OOM killer *later*, when it touches pages it was promised. Shared libraries and the page cache are the same frames mapped into many processes, which is why summed RSS exceeds RAM.
Green flags · Red flags
- Lists isolation, relocation, sharing and lazy allocation before swapping
- Describes pages, frames, page tables and permission bits
- Treats page faults as the normal mechanism, not an error
- Names the TLB as the answer to translation cost
- Explains RSS vs VSZ and overcommit
- "Virtual memory is swap space"
- Believes VSZ is memory used
- Cannot explain why malloc of 1 GB is instant