virtual memory

Imagine an apartment building where every tenant is handed identical blueprints that say 'your home runs from room 0 to room 1,000,000, and it is all yours.' Each tenant decorates their rooms believing they own that whole stretch — yet behind the walls a building manager quietly maps each tenant's 'room 412' onto some real, scattered cupboard in the actual building, and no two tenants ever touch the same cupboard by accident. Virtual memory is exactly this illusion for programs: each program is told it owns a huge, private, neatly numbered block of memory, while the hardware secretly maps those make-believe addresses onto wherever the real memory happens to be.

More precisely, virtual memory is the combination of two things: address translation (every memory address a program uses is a virtual address that gets converted to a physical address before it reaches the actual memory chips) and protection (the translation machinery also checks whether this program is allowed to touch this location at all). The translation is done in fixed-size chunks: memory is divided into pages, a page table records which physical frame each virtual page currently lives in, and a hardware unit called the MMU performs the lookup on every access. If a needed page is not in physical memory, a page fault traps to the operating system, which fetches it from storage.

Be honest about what virtual memory is and is NOT. It is NOT 'extra RAM' and its point is NOT swapping to disk — swapping is just a side effect that happens when you run out of room. The real purpose is three-fold: run programs larger than physical memory, isolate and protect processes from one another so a bug in one cannot corrupt another, and let the loader place a program anywhere in physical memory without rewriting its addresses. It is a hardware/OS co-design: the MMU translates fast in hardware, but the OS owns the page tables and handles faults. Neither alone suffices, and a TLB miss or page fault can dominate run time.