Introduction to Memory Management

Tanenbaum Chapter 3: Why operating systems manage memory, the memory hierarchy, and the illusion of virtual address spaces.

1. Why Does an Operating System Manage Memory?

Every program you run—from a web browser to an operating system kernel—consists of machine instructions executing on a CPU. But a processor cannot execute instructions directly from a hard drive or SSD. Instructions and their data must be loaded into Main Memory (Physical RAM) before the processor's fetch-execute cycle can touch them.

In an ideal computer world, programmers would have infinite memory that is infinitely fast, completely nonvolatile (never loses data on power-off), and dirt cheap. In physical reality, no such hardware technology exists.

The Memory Hierarchy Dilemma

Computer architecture resolves this mismatch through a tiered memory hierarchy. As you move closer to the CPU, storage becomes radically faster, exponentially more expensive, and drastically smaller in capacity:

Storage Tier Typical Access Time Typical Capacity Managed By
CPU Registers < 0.5 ns (1 cycle) < 2 KB Compiler / Assembly programmer
L1 / L2 / L3 CPU Caches 1 – 15 ns (3–40 cycles) 32 KB – 64 MB CPU Hardware automatically
Main Physical Memory (DRAM) 50 – 100 ns (150–300 cycles) 8 GB – 128 GB Operating System (Memory Manager)
Solid-State Drive (NVMe SSD) 20 – 100 μs (100,000 cycles) 512 GB – 4 TB Operating System (File System / Swap)
Magnetic Hard Disk 5 – 10 ms (10,000,000 cycles) 2 TB – 20 TB Operating System (File System)
Notice the chasm: Accessing physical DRAM takes ~100 nanoseconds, while reading from an SSD takes ~50 microseconds (500x slower), and a hard drive takes 10 milliseconds (100,000x slower!).

2. The Two Core Responsibilities of Memory Management

The memory management subsystem inside an operating system kernel carries out two primary functions:

Role A: Abstraction (The Virtual Memory Illusion)

Without memory management, software would directly reference raw physical pins on DRAM chips. If Program A wrote to physical address 0x1000, and Program B simultaneously wrote to 0x1000, they would corrupt each other's state instantly.

The operating system solves this by creating an abstraction called Virtual Memory. Every process is given the illusion of having a clean, private, uniform address space starting at virtual address 0x00000000 and extending up to gigabytes or terabytes. A process has no idea—and does not need to know—where its bytes physically sit in DRAM chips.

Role B: Protection and Isolation

Programs are inherently imperfect and prone to bugs (such as stray pointers, buffer overflows, or unauthorized access). The OS ensures that:

  • Process A cannot read, write, or tamper with the memory belonging to Process B.
  • Userland applications can never overwrite the operating system kernel's private memory structures.

3. Hands-On Demonstration: The Address Space Illusion

Consider running two separate terminal windows, both running the exact same binary program (for example, two instances of the shell bash). Both processes execute instructions starting at the exact same virtual address: 0x00400000.

How can two different programs occupy the exact same address at the same time without colliding?

Process A (PID 1024) Virtual Address Space
0x00400000 Code (main)
0x00600000 Heap (malloc)
0x7FFF0000 User Stack
⇋ Hardware MMU Translates on the fly ⇋
Physical DRAM Chips Actual hardware frames
PFN 42 Process A (Code)
PFN 55 Process B (Code)
PFN 78 Process A (Heap)
PFN 91 Process B (Heap)
PFN 102 Process A (Stack)

Click on any virtual address above. Notice how the hardware MMU maps both processes to completely independent physical frames in DRAM!

Step 1 of 4 What Comes Next in Chapter 3?
1. The Need for Granular Paging