Why Virtual Memory?

Early machines ran one program at a time with physical addresses: the address in the instruction was the address on the memory bus. Running two programs meant one of two bad options. Relocate at load time — patch every address in the binary to wherever it happened to land — which works until the program is swapped out and reloaded elsewhere, and does nothing to stop it reading its neighbour. Or give each program a base and bound register pair: the hardware adds the base to every address and faults if the result exceeds the bound. That provides isolation and relocation, but only for one contiguous block per program, so memory fragments as programs of different sizes come and go, and there is no way to share a library between two programs or to run a program larger than RAM.

The requirements that accumulated over the 1960s and 70s are the ones we still have: each process wants a contiguous private address space starting wherever its linker chose; the OS wants to place processes anywhere in RAM, move them, and reclaim pieces; processes must not read or corrupt each other or the kernel; shared code (libc is mapped into nearly every process) should exist once in RAM; and the sum of what processes *reserve* should be allowed to exceed what physically exists, because most of it is never touched at the same time.

Instead of one base register per process, give every process a map. Chop both the virtual address space and physical RAM into fixed-size pages (4 kB is the common choice; see Paging) and keep, per process, a table that says for each virtual page which physical frame holds it — or that it holds nothing yet. The CPU’s memory management unit (MMU) consults that table on every access, transparently, so the program sees only virtual addresses and the memory bus sees only physical ones. The kernel owns the tables; user code cannot even see them (User Mode vs Kernel Mode).

One indirection, and every requirement falls out. Two processes both using virtual address 0x400000 have two table entries pointing at two different frames — isolation and relocation at once, and a process can be moved by editing its table. An entry marked "not present" costs no RAM until it is touched — lazy allocation and overcommit. Two tables pointing at the same frame — sharing, so libc’s code exists in RAM once. Permission bits on each entry — protection: code is read-only and executable, data is writable and not executable, kernel pages are inaccessible from user mode. And a page that has been written to disk can be marked not-present and restored on demand — swap, and running programs larger than RAM.

Each property below is a consequence of the same table; none needs separate hardware. That is the reason virtual memory won over every alternative: it is a single mechanism with a single cost, not five features with five costs.

Between base-and-bound and paging came segmentation: divide a program into a few variable-sized logical segments (code, data, stack, each library), each with its own base, bound and permissions. It solved sharing and protection per segment and matched how programmers thought about programs. It did not solve fragmentation — segments are variable-sized, so RAM fills with unusable holes — and it made the address two-part (segment selector plus offset), which every compiler and programmer had to reason about. 16-bit x86 real mode and 32-bit protected mode carried segments; Multics and the Burroughs machines built whole systems on them.

Paging won because fixed-size pages fragment only inside a page (at most 4 kB wasted per mapping) and never between pages, and because the map can be walked by hardware without the program knowing. x86-64 effectively retired segmentation: the segment bases are forced to zero in 64-bit mode (with FS/GS surviving as thread-local-storage base registers), and ARM never had it. Where segmentation’s ideas live on is in the *permissions* per region — a modern process’s address space is a list of regions with different protections, mapped over pages.

The table has to be consulted on every memory access, and it lives in memory — so a naive implementation doubles the cost of every load and store, and a multi-level table (Page Tables) makes it four or five extra loads. The whole design is viable only because the CPU caches translations in the The TLB, which hits on the vast majority of accesses. When it misses, or when a page is not present, the cost is a page-table walk or a trap (Page Faults) — and when the working set exceeds RAM, the cost is thrashing (Memory Pressure, Swap and the OOM Killer). Every remaining lesson in this module is about one of those costs and the machinery that keeps it small.

The other cost is the tables themselves. A process’s page tables are real memory (a few MB for a process with a few GB mapped; the kernel’s own tables for a 1 TB machine are gigabytes), a context switch has to change the active table (Context Switching), and the kernel spends real effort keeping many tables coherent when a shared page changes (TLB shootdowns across cores). Huge pages exist to shrink all three.