Virtual Memory: Giving Every Program Its Own Private Address Space

Programs behave as if they have access to a huge, private block of memory, even though physical RAM is limited and shared among many running processes. This article explains how virtual memory creates this illusion through address translation, how page tables and the TLB make translation fast, and what happens when needed data is not currently in physical memory.

Virtual MemoryPage TablesTranslation Lookaside Buffer

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱۵ شهریور ۱۴۰۵

The Illusion Virtual Memory Provides

Every running program behaves as though it has its own large, private, continuous block of memory starting from address zero, completely unaware of other programs running simultaneously or of how much physical memory the machine actually has. This illusion is created by Virtual Memory, a mechanism that separates the addresses a program uses from the actual physical memory locations where data is stored.

Two Kinds of Addresses

A program works exclusively with Virtual Addresses, while the actual hardware memory is organized by Physical Addresses. Every memory access a program makes must be translated from a virtual address to the corresponding physical address before the actual hardware can retrieve or store the data.

Pages: The Unit of Translation

Rather than translating individual bytes one at a time, memory is divided into fixed-size chunks called Pages. Each virtual page maps to a physical Frame of the same size, and this mapping is recorded in a data structure called the Page Table, maintained by the operating system.

Virtual Address:
[ Virtual Page Number | Page Offset ]

Page table lookup:
Virtual Page Number → Physical Frame Number

Physical Address:
[ Physical Frame Number | Page Offset ]

Why Translation Needs to Be Fast

Since every single memory access requires a translation, consulting the full page table in main memory for every access would be far too slow. To solve this, hardware includes a small, specialized cache called the TLB (Translation Lookaside Buffer), which stores recently used virtual-to-physical translations directly, similar in spirit to the caching principles discussed earlier in this series. A TLB hit allows translation to happen almost instantly, while a TLB miss requires consulting the full page table, which is significantly slower.

What Happens When Data Is Not in Physical Memory

Because virtual memory allows a program to behave as though it has more memory than is physically installed, some virtual pages may not currently reside in physical memory at all, instead being stored on disk. When a program accesses such a page, a Page Fault occurs: the operating system pauses the program, retrieves the needed page from disk, places it into physical memory, updates the page table accordingly, and then resumes the program's execution as though nothing unusual happened.

Why Virtual Memory Also Provides Protection

Beyond enabling programs to use more memory than physically available, virtual memory provides a critical protection benefit: because each program only has visibility into its own virtual address space, it cannot directly read or corrupt the memory belonging to another running program, since the operating system controls each program's page table and simply never maps its addresses onto another program's physical memory.

Why This Mechanism Is Essential to Modern Computing

Without virtual memory, running multiple independent programs safely and simultaneously would require far more careful and fragile manual memory management, and programs would need to be aware of exactly how much physical memory the machine has and where other programs are located — a level of complexity that virtual memory hides entirely, allowing software to be written far more simply and safely.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Common Misconceptions About Parallel Computing and the Book's Final Lessons

After covering everything from thread-level parallelism to warehouse-scale computing, it is worth correcting persistent misconceptions about parallel systems that even experienced engineers sometimes hold. This article addresses common fallacies about scaling and parallel hardware, then closes out the parallel processing chapter by tying together the full journey from a single instruction to a building full of cooperating machines.

ادامه

Real Stuff: Benchmarking CPUs Against GPUs and Multiprocessor Matrix Multiply

Comparing a CPU and a GPU fairly requires a model that accounts for both computational throughput and memory bandwidth limits together. This article introduces the roofline model used to compare real hardware like the Intel Core i7 and NVIDIA Tesla GPU, then shows how matrix multiplication is accelerated across multiple processors as the final practical application of this chapter's parallel concepts.

ادامه

Benchmarking Multiprocessors and Modeling Parallel Performance

Measuring the performance of a parallel system requires different tools and metrics than measuring a single-core processor. This article covers the specialized benchmarks used to evaluate multiprocessor systems, explains how to model scaling behavior as more processors are added, and revisits Amdahl's Law in the context of real-world performance measurement.

ادامه

Cluster Networking: Connecting to the World Outside

A cluster of machines is only useful if it can communicate efficiently both internally and with the outside world. This article covers the networking layers involved in cluster communication, the tradeoffs between latency and bandwidth at scale, and how clusters connect to external networks and users.

ادامه

Clusters, Warehouse-Scale Computers, and Network Topologies

Beyond a single chip, parallelism extends to entire buildings full of independent computers working together. This article explains the shift from shared memory multiprocessing to clusters of separate machines, introduces the concept of warehouse-scale computing, and covers the network topologies that connect these independent machines efficiently.

ادامه

An Introduction to GPUs: Massive Parallelism for Data-Heavy Workloads

A GPU takes the SIMD idea covered earlier in this series to an extreme scale, running thousands of lightweight threads simultaneously to process massive amounts of independent data. This article explains why GPUs are architecturally so different from CPUs, how their thread execution model works, and what kinds of workloads benefit most from this design.

ادامه