3.1 Physical Memory vs. Virtual Memory

Physical memory is the real hardware: the RAM sticks installed on your motherboard. It has real addresses that match real places on the chips.

Virtual memory is an illusion. The operating system (with help from the CPU) gives every process (a running program) its own private address space that looks huge. That space is completely separate from every other process's space, and from the real layout of the RAM.

Analogy: Think of a hotel. Every guest holds a key card for "Room 1". Each guest thinks Room 1 is theirs. The front desk secretly maps each guest's "Room 1" to a different real room. Nobody can walk into somebody else's room, because their key card does not know the real room numbers.

Physical RAM (real, shared, finite):
┌───────────────────────────────────────────────┐
│  [Chrome's data] [Word's data] [Game's data]  │  16 GB total, one shared pool
└───────────────────────────────────────────────┘

Virtual memory (fake, private, per-process):
Chrome's view:        Word's view:          Game's view:
┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ 0 → huge     │      │ 0 → huge     │      │ 0 → huge     │
│ address space│      │ address space│      │ address space│
│ "all mine"   │      │ "all mine"   │      │ "all mine"   │
└──────────────┘      └──────────────┘      └──────────────┘

Every process believes it owns one complete, unbroken address space that starts near address 0. None of them can see, or even tell about, the memory of the others. This illusion is virtual memory. It works quietly in the background: no program has to do anything special to get it.

3.2 Address Space: 32-bit vs. 64-bit

An address space is the full range of addresses a process can use. Its size depends on how many bits are used to write an address. This links back to the x86 vs. x64 talk in Chapter 2, Section 8.

32-bit address space:  2^32 = 4,294,967,296 bytes  = 4 GB maximum
64-bit address space:  2^64 = a number so large it's not a practical limit
                        (Windows itself further limits this to 128 TB–256 TB
                         per process, still vastly beyond real-world RAM sizes)

(2^32 means "2 multiplied by itself 32 times".)

This is why old 32-bit programs can use at most 4 GB each, no matter how much RAM is installed: the addresses simply cannot count any higher. A 64-bit process has no such practical limit.

32-bit64-bit
Address space4 GBEnormous (Windows allows 128 TB–256 TB per process)
Limit in practiceYes, 4 GB per programNo real-world limit

3.3 Virtual Addresses vs. Physical Addresses

A virtual address is the address a program's instructions use. For example, MOV EAX, [0x00401000] means "read from virtual address 0x00401000" — as far as the program knows.

A physical address is where that data really sits in the RAM chips.

Program says: "read from virtual address 0x00401000"
                            │
                            ▼
              (translated behind the scenes —
               see Section 4, the MMU)
                            │
                            ▼
          Actual physical RAM address: 0x1A2B3000

The program never sees the physical address. The hardware (the MMU) and the OS do the translation, invisibly, on every single memory access. And here is the important part: two different processes can use the exact same virtual address (say both have something at 0x00400000), yet they land on two completely different places in real RAM that never overlap.

3.4 Why Virtual Memory Matters

Virtual memory is not just a clever trick. It solves several hard problems at once:

  • Isolation: A process only ever holds virtual addresses. It cannot even write down a physical address, so it cannot read another process's memory by accident or on purpose. The CPU hardware enforces this, which is much stronger than a rule enforced by software alone.
  • Abstraction: Programs are built without knowing how much RAM the PC has, or where in RAM they will land. The linker (the tool that joins a program's pieces together) can assume nice, predictable virtual addresses every time.
  • Efficient memory use: Not all of a process's address space needs real RAM at every moment. Parts can be mapped in only when they are actually used (see the page faults in Section 5), and rarely used parts can be moved out to storage for a while.
  • Looking bigger than the installed RAM: Together with paging (Section 5), virtual memory lets the total demand of all running programs exceed the installed RAM, by parking less-active data on storage for a while.

3.5 Process Address Space Layout

A typical Windows process has its virtual address space split into regions in a set order. (This is a preview; Section 6 covers it in full.)

High addresses  ┌─────────────────────────────┐
                │   Kernel-mode memory        │  ← shared, protected,
                │   (mapped into every        │    inaccessible from
                │    process, but protected)  │    user mode
                ├─────────────────────────────┤
                │   Stack (grows downward)    │
                ├─────────────────────────────┤
                │         ...unused...        │
                ├─────────────────────────────┤
                │   Heap (grows upward)       │
                ├─────────────────────────────┤
                │   Loaded DLLs               │
                ├─────────────────────────────┤
                │   Data segment (globals)    │
                ├─────────────────────────────┤
                │   Code segment (the program)│
Low addresses   └─────────────────────────────┘

Every user-mode process gets its own private copy of everything below the kernel region. This steady, predictable layout is one reason why crash dumps and debugging tools look alike across different runs and different machines.

Summary

TopicRemember this
Physical memoryThe real RAM chips, shared by everyone
Virtual memoryA private, huge-looking address space for each process
32-bit vs 64-bit4 GB maximum vs. a practically unlimited space
Virtual vs physical addressThe program uses virtual ones; the MMU translates them to physical ones
Why it mattersIsolation, abstraction, efficient use, and "more memory than installed"
LayoutCode, data, DLLs, heap, stack and kernel regions, in that order from low to high