The short answer
Quick answer: Virtual memory gives every process its own private, continuous range of memory addresses, regardless of how much physical RAM exists or how it is being used. The CPU and operating system translate each virtual address into a physical address on the fly, using per-process page tables. This lets programs be isolated from each other, lets the system load data only when it is needed, and lets total memory use exceed physical RAM by moving idle pages to disk.
The problem it solves
Imagine programs used physical RAM addresses directly. Three problems appear immediately:
- No protection. Any program could read or overwrite another program's memory, or the operating system's.
- Fragmentation. A program needing one large block might not find one, even if plenty of small gaps are free.
- Hard limits. Programs could never use more memory in total than is physically installed, and every program would have to know where it was loaded.
Virtual memory solves all three with one level of indirection.
Pages and frames
Memory is divided into fixed-size chunks:
- A page is a chunk of virtual memory.
- A frame is a chunk of physical RAM of the same size.
The common page size is 4 KB, though systems also support larger "huge pages". An address is split into two parts: the page number and an offset within the page. Translation only changes the page number; the offset stays the same.
Because any virtual page can map to any physical frame, a program's memory can be scattered all over RAM while still looking like one neat continuous block.
Page tables: the map
Each process has a page table that records, for every virtual page, which physical frame holds it and what may be done with it:
| Entry field | Meaning |
|---|---|
| Frame number | Where the page lives in physical RAM |
| Present bit | Is the page in RAM right now? |
| Read / write / execute bits | What access is allowed |
| User / kernel bit | May ordinary code touch it? |
| Accessed and dirty bits | Has it been used or modified recently? |
A 64-bit address space is vast, so a flat table would be impossibly large. Real systems use multi-level page tables: a tree where whole branches for unused regions simply do not exist. On x86-64, a lookup typically walks four levels.
The hardware component that performs this translation is the memory management unit (MMU), built into the CPU.
The TLB: making translation fast
Walking a four-level table on every memory access would be painfully slow. So the CPU keeps a small, very fast cache of recent translations called the translation lookaside buffer (TLB).
- TLB hit: the translation is found instantly.
- TLB miss: the CPU walks the page table, then stores the result in the TLB.
Programs that touch memory in a compact, predictable pattern get many TLB hits. Programs that jump around huge amounts of memory get more misses. This is one reason huge pages help database servers: fewer, bigger pages mean each TLB entry covers more memory. The TLB is separate from, but works alongside, the CPU cache.
Page faults: loading on demand
What if a program touches a page that is not currently in RAM? The CPU raises a page fault and hands control to the operating system. Despite the name, most page faults are normal:
- Minor fault. The data is already in RAM (for example, a shared library another process loaded) and only the mapping needs to be created.
- Major fault. The data must be read from disk, which is far slower.
- Invalid access. The address is not mapped at all, or the access breaks the permissions. The process is stopped with a segmentation fault.
This mechanism enables several important tricks:
- Demand paging. When you run a program, its file is mapped but not read. Pages are loaded the first time they are used.
- Lazy allocation. Asking for 1 GB of memory is nearly instant, because physical frames are only assigned when each page is first written.
- Copy-on-write. After
fork(), parent and child share the same frames, marked read-only. A frame is copied only when one of them writes to it. - Memory-mapped files. A file can be made to appear as a region of memory, and the OS loads and saves pages automatically.
The Linux memory management concepts guide describes how the kernel implements each of these.
Swapping: using disk as overflow
When physical RAM runs low, the operating system picks pages that have not been used recently and frees their frames:
- Pages backed by a file (such as program code) can simply be dropped and re-read later.
- Pages with no file behind them (such as heap data) are written to swap space on disk first.
If the program later touches a swapped-out page, a major page fault brings it back. This lets a system run more than fits in RAM, at a price: disk is vastly slower than memory. When the system spends most of its time swapping, performance collapses. That is the subject of why your computer slows down when RAM fills up.
What a process's address space looks like
Every process sees roughly the same layout: its code, global data, a heap that grows as it allocates memory, shared libraries, and a stack for each thread. Large stretches in between are unmapped. The kernel is mapped into a protected part of every address space too, so system calls do not need a full address space switch. For the difference between the two main working regions, see stack vs heap.
Frequently asked questions
Is virtual memory the same as swap?
No. Virtual memory is the whole system of address translation, which is always on. Swap is one feature built on top of it, used only when RAM runs short.
Does virtual memory make programs slower?
Translation adds a small cost, mostly hidden by the TLB. In return you get isolation, demand loading and sharing, which make the system as a whole faster and far more reliable.
How much memory can a process address?
On 64-bit systems, typically 128 TB or more of virtual address space, far beyond installed RAM. The practical limit is physical memory plus swap.
Why does a program's memory use look so large in monitoring tools?
Tools often show virtual size, which counts everything mapped, including files and memory that was reserved but never touched. Resident size (RSS) shows what is actually in RAM.
Conclusion
Virtual memory is one of the most successful ideas in computing: add a translation layer between programs and RAM, and you get protection, flexibility and efficiency all at once. Page tables define the mapping, the TLB makes it fast, and page faults let the operating system fill in memory only when it is truly needed.
Related articles
- Why Your Computer Slows Down When RAM Fills Up
- What Actually Happens When You Run a Program
- How the CPU Cache Makes Code Fast (and How to Write Cache-Friendly Code)
- Stack vs Heap: Where Your Variables Actually Live
Sources and further reading
