Virtual Address Space

Every program you run believes it owns the entire machine. When you write a C program that declares an array of a million integers, it doesn't negotiate with other programs for space. When a web browser opens dozens of tabs, each tab operates as if it has uncontested access to memory. This isn't naivety on the part of your programs—it's the result of one of the most elegant abstractions in computer science: the virtual address space.

The virtual address space is a fundamental illusion maintained by the operating system and hardware working in concert. Each process is given its own private, contiguous address space that appears to span from address 0 to some maximum value (like 2⁴⁸ - 1 on 64-bit systems). This space is completely independent of physical memory, completely isolated from other processes, and completely under the control of the operating system.

Understanding virtual address spaces isn't just academic knowledge—it's essential for debugging memory issues, understanding security vulnerabilities, optimizing program performance, and designing systems that scale. This page provides a comprehensive exploration of this critical concept.

A virtual address space is the logical view of memory as seen by a running process. It is an abstraction that presents each process with its own private, contiguous range of addresses, completely independent of the actual physical memory layout or the presence of other processes in the system.

The key insight: From a process's perspective, it is the only entity using memory, and that memory forms a single, unbroken sequence of addresses starting from zero. This is fundamentally different from the physical reality, where:

• Physical memory is shared among all processes
• Physical memory may not be contiguous for any single process
• Physical memory has a fixed, finite size
• Other processes occupy portions of physical memory simultaneously

A virtual address space has a well-defined structure, divided into distinct regions that serve specific purposes. Understanding this layout is crucial for debugging, security analysis, and performance optimization.

The canonical layout (from low addresses to high addresses):

The exact layout varies by operating system and CPU architecture, but the conceptual organization follows consistent principles across platforms.

The heap-stack gap:

The large unmapped region between the heap and stack serves multiple purposes:

1. Growth accommodation — Both heap and stack can grow into this space without colliding
2. Security — Makes it harder to predict addresses for exploitation
3. Flexibility — Allows memory-mapped files to be placed in this region
4. ASLR support — Enables randomization of library load addresses

Why this layout matters:

The separation of code (text) from data isn't arbitrary—it enables crucial optimizations and security features:

• Code sharing — Multiple instances of the same program can share the text segment
• Write protection — Code pages can be marked read-only, preventing code injection
• Execution prevention — Data pages can be marked non-executable (DEP/NX bit)
• Copy-on-write — Forked processes initially share all segments until modification

Let's examine how virtual addresses manifest in real programs. Understanding these concrete details bridges the gap between abstract concepts and practical debugging.

Examining a process's memory map:

On Linux systems, you can examine the virtual address space of any process by reading /proc/[pid]/maps. Here's an annotated example:

Understanding the permission flags:

Each memory region has four permission characters:

The virtual address space is sparse:

Notice the gaps between memory regions. Not all addresses in a virtual address space are valid—attempting to access an unmapped address triggers a segmentation fault (SIGSEGV on Unix systems). This sparsity is actually beneficial:

• Memory efficiency — Only used regions consume physical memory or page table entries
• Security — Invalid access is immediately detected
• Flexibility — Regions can be added or resized dynamically

The size of a virtual address space is determined by the CPU's addressing capability—specifically, the number of bits in a virtual address.

32-bit vs 64-bit addressing:

Why x86-64 uses only 48 bits:

Although 64-bit registers can hold 64-bit addresses, current x86-64 implementations use only 48 bits for virtual addresses. This isn't hardware limitation but practical design:

1. Page table size — Full 64-bit addressing would require enormous page tables
2. Physical constraints — No current system needs 16 exabytes of virtual space
3. Future expansion — The architecture allows future CPUs to extend to more bits

Canonical addresses:

In x86-64, valid addresses must be 'canonical'—bits 48-63 must all be copies of bit 47. This creates two valid ranges:

• User space: 0x0000000000000000 to 0x00007fffffffffff (lower 128 TB)
• Kernel space: 0xffff800000000000 to 0xffffffffffffffff (upper 128 TB)

The 'hole' in the middle (non-canonical addresses) is reserved for future expansion.

One of the most powerful properties of virtual address spaces is isolation: each process has its own independent address space. This isolation is absolute—there is no direct way for one process to access another's memory through virtual addresses.

The implications of independence:

Same virtual address, different physical locations:

Consider two processes, A and B, running simultaneously. Both might have code loaded at virtual address 0x400000 and stack at 0x7fff00000000. These identical virtual addresses refer to completely different physical memory locations.

The translation mechanism:

The CPU's Memory Management Unit (MMU) maintains separate page tables for each process. When Process A is running, the MMU uses Process A's page tables to translate virtual addresses to physical addresses. When the OS context-switches to Process B, it switches the active page table, and now the same virtual addresses translate to Process B's physical pages.

Context switch and address space:

A virtual address is not just a single number—it's a structured value composed of multiple fields, each serving a specific purpose in the address translation process. Understanding this structure is essential for grasping how virtual memory works at the hardware level.

The fundamental split: page number and offset

Every virtual address is divided into at least two parts:

1. Virtual Page Number (VPN) — Identifies which page of the virtual address space
2. Page Offset — Identifies the specific byte within that page

For a system with 4 KB pages (2¹² bytes):

Multi-level page tables add more fields:

Modern systems use hierarchical page tables to avoid having a single enormous page table. This means the VPN is further subdivided:

The terminology around memory addresses can be confusing, as different architectures and textbooks use varying terms. Let's clarify the distinctions:

In most modern systems, these terms are effectively synonymous:

• Virtual Address — The address a program uses; undergoes translation to physical
• Logical Address — Often used interchangeably with virtual address
• Linear Address — In x86 terminology, the address after segmentation but before paging

The x86 historical context:

In legacy x86 systems with segmentation, there was a distinction:

1. Logical Address = Segment:Offset (what the program specifies)
2. Linear Address = After segment translation (segment base + offset)
3. Physical Address = After page translation (what appears on memory bus)

In modern x86-64 long mode, segmentation is essentially disabled (flat memory model), so logical ≈ linear ≈ virtual.