How Hardware Virtual Memory Translates Addresses

Hardware virtual memory translation converts a program’s virtual address into a physical address using a page table and a small cache called the TLB, all managed by the CPU’s MMU. When a program accesses memory, the MMU splits the virtual address into a virtual page number and an offset, looks up the page table to find the corresponding physical frame, and combines it with the offset. This happens on every memory access, and the TLB speeds it up by caching recent translations.

Why Virtual Memory Exists

Virtual memory gives each process its own private, contiguous address space, isolated from other processes and the physical RAM. This lets programs use more memory than physically available (via paging to disk), simplifies memory management, and provides protection—a process cannot read or write another process’s memory because the translation maps only its own pages. Without it, every program would need to know exactly where other programs are in RAM, leading to fragmentation and security holes.

The MMU and Page Tables

The Memory Management Unit (MMU) is the hardware component that performs translation. It reads the page table, which is a data structure stored in RAM that maps virtual page numbers (VPN) to physical frame numbers (PFN). Each page table entry (PTE) contains the PFN plus flags like present, read/write, user/supervisor, and accessed/dirty bits.

On a 64-bit system with 4 KB pages, a page table would need 2^52 entries per process—impossible. So, multi-level page tables are used: the virtual address is split into several parts, each indexing a different level. For example, x86-64 uses 4 levels (PML4, PDPT, PD, PT), each with 512 entries. The MMU walks these levels, reading a PTE at each step, until it reaches the final PTE that gives the physical frame.

The TLB: A Translation Cache

Walking a 4-level page table on every memory access would be horribly slow—4 memory references per access. The Translation Lookaside Buffer (TLB) is a small, very fast cache inside the CPU that stores recent VPN-to-PFN mappings. On a memory access, the MMU first checks the TLB. If the translation is present (a TLB hit), it uses it immediately. If not (a miss), it performs the page table walk and then caches the result.

TLBs are typically split into instruction (ITLB) and data (DTLB) caches, and often have multiple levels (L1, L2). They are also tagged with an Address Space Identifier (ASID) to avoid flushing on every context switch—each process has a unique ASID, so translations from different processes don’t collide.

Translation Steps in Detail

Here is the exact sequence for a memory access on a typical x86-64 system:

1. Check TLB: The MMU looks up the virtual page number in the TLB. If hit, go to step 5.
2. Page table walk: The MMU uses the CR3 register to find the PML4 table base. It uses bits 39-47 of the virtual address to index PML4, then bits 30-38 to index PDPT, bits 21-29 to index PD, bits 12-20 to index PT.
3. Check PTE: The final PTE is read. If the present bit is 0, a page fault occurs—the OS must load the page from disk or allocate a new one. If present, continue.
4. Update TLB: The translation is cached in the TLB, possibly evicting an old entry.
5. Generate physical address: The physical address = (PFN << 12) + offset. The offset is the lower 12 bits of the virtual address.
6. Access memory: The CPU sends the physical address to the memory controller.

This entire process takes only a few nanoseconds on a TLB hit, and about 10-30 nanoseconds on a miss (plus page fault time if needed).

Page Faults and OS Interaction

When a PTE’s present bit is 0, the MMU raises a page fault exception. The OS handler runs, examines the faulting address, and determines the cause:

• Invalid access: The address is not mapped (e.g., null pointer dereference). The OS sends a segmentation fault signal to the process.
• Protection violation: The process tried to write to a read-only page, or execute a non-executable page. Similar handling.
• Demand paging: The page is mapped but not in RAM (swapped out). The OS reads it from disk, updates the PTE, and resumes the process.
• Copy-on-write: The page is shared and read-only; on write, the OS copies it and updates the PTE.

After handling, the OS must flush the TLB entry (or the entire TLB) if the mapping changed, using instructions like invlpg on x86.

Common Misconceptions

One common misconception is that virtual addresses are the same as physical addresses. They are not—virtual addresses are per-process and can be non-contiguous. Another is that the TLB is a software cache; it is entirely hardware-managed in most CPUs, though some architectures (like MIPS) use software-filled TLBs where the OS must handle misses via a special exception.

Another misconception: 64-bit systems do not actually use all 64 bits for addresses. Current x86-64 supports only 48 bits of virtual address space (256 TB), with the upper bits sign-extended. This is enough for now, but future CPUs may extend it.

Frequently Asked Questions

What is the difference between virtual and physical address?

A virtual address is what a program uses; it is translated by the MMU to a physical address that points to actual RAM. Virtual addresses are per-process and can be swapped, while physical addresses are global and fixed.

Why is the TLB necessary?

Without the TLB, every memory access would require a multi-level page table walk, which would be 4-5 times slower. The TLB caches translations, making the common case fast.

What happens when the TLB is full?

When a new translation is needed and the TLB has no free entries, the MMU evicts an existing entry, often using a pseudo-LRU or random policy. This can cause a TLB thrashing if the working set is too large.

How does the OS know which pages are in RAM?

The present bit in each PTE indicates if the page is in physical memory. If not, the OS uses the page table entry’s other bits (like a swap location) to find it on disk.

Can a process access another process’s memory?

No, because each process has its own page table. The MMU only translates addresses according to the current page table, so a process cannot reference another process’s physical frames unless the OS explicitly maps them (e.g., shared memory).

Does virtual memory affect performance?

Yes, but modern hardware minimizes it. TLB hits are nearly free, and page faults are rare. However, programs with poor locality can cause TLB misses and page faults, slowing them down significantly.

Related

• Patreon vs Ko-fi: Which Is Better for Creators?
• Reasons Need Firewall Boost Security?
• Recover Deleted Safari History on Mac: Full Guide