Skip to main content

Source: Operating Systems: Three Easy Pieces (OSTEP) — Chapter 13, Arpaci-Dusseau & Arpaci-Dusseau

The Abstraction: Address Spaces

Users expect ease of use, performance, reliability — and that is why virtual memory exists.

Early systems​

Early machines offered little memory abstraction. Physical RAM looked roughly like this:

RegionContents
Low addresses (e.g. 0)OS — a library of routines
Rest of memoryOne running program (e.g. starting at 64 KB)

Few illusions; users expected little. Life was simple for OS developers.

Multiprogramming and time sharing​

Machines were expensive → multiprogramming [DV66]: several processes ready; OS switches when one blocks on I/O.

Then time sharing [S59, L60, M62]: many interactive users; each wants a timely response.

Naive approach: run one process with all of memory, then save entire RAM to disk, load the next process — far too slow as memory grows.

Better: leave processes in memory while switching the CPU (Figure 13.2). Three processes A, B, C each occupy a slice of 512 KB physical RAM; the OS runs one while others wait Ready.

New requirement: protection — one process must not read or write another’s memory.

The address space​

The OS must provide an easy abstraction of physical memory: the address space — the running program’s view of memory.

It holds the program’s memory state:

RegionRole
CodeInstructions (static; fixed size at load)
Heapmalloc / new — dynamic, grows
StackLocals, args, return addresses — grows on calls

Plus static data and more in real binaries; these three are the core picture.

A tiny 16 KB example (Fig 13.3)​

code     [0 – 1 KB)
heap     grows from 1 KB downward (toward stack)
(free)   middle gap
stack    grows upward from the high end (16 KB)

Placement is convention — other layouts exist (especially with threads sharing one space).

Critical distinction: the diagram is the abstraction. In Figure 13.2, A, B, C sit at different physical addresses. Process A’s load from virtual address 0 must land at A’s physical frame (e.g. 64 KB), not at physical 0.

Crux: how does the OS build a private, potentially large address space for each process on one shared physical memory?

That translation — virtual → physical — underlies every modern system.

Isolation

Isolation lets one component fail without breaking others. Memory isolation keeps processes (and often the kernel) from harming each other — a step toward reliable systems and microkernel designs [BH70, R+89, S+03].

VM goals​

Three goals guide the memory chapters (same themes as the OS intro):

GoalMeaning
TransparencyPrograms behave as if they have private physical memory — the illusion is invisible (confusing word: “transparent” = hard to notice)
EfficiencyLow time and space overhead — hardware help (e.g. TLB)
ProtectionLoads/stores/fetches cannot touch other processes or the OS — isolation

Every address you see is virtual​

Print a pointer in C? Virtual. Print main? Virtual. malloc result? Virtual. Stack local? Virtual.

Only the OS + hardware know physical locations.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    printf("location of code  : %p\n", (void *) main);
    printf("location of heap  : %p\n", (void *) malloc(1));
    int x = 3;
    printf("location of stack : %p\n", (void *) &x);
    return x;
}

On a 64-bit Mac, typical output:

location of code  : 0x1095afe50
location of heap  : 0x1096008c0
location of stack : 0x7fff691aea64

Code low, heap next, stack far away — all virtual; translation happens on every access.

Interactive: physical vs virtual layouts​

Try: early single-program · multiprogramming · 16 KB layout · virtual→physical translation.

Check your understanding​

Quiz

Address spaces

1 / 6

Swapping an entire process’s physical memory to disk between time slices is…

Pick an answer to see if you are right.

Coding challenges​

Python models for segment layout and simple relocation — preview of base/bounds.

Homework lab: inspect real address spaces​

Run on a Linux machine (or WSL). Tools won't run in the Piston sandbox — this lab is for your own system.

Lab

Homework: free, memory-user, pmap

0/7 started

Loading lab…

Summary​

IdeaOne line
Early OSOS low in RAM; one program; no illusion
Time sharingKeep processes in memory; switch CPU — don't dump all RAM
Address spaceProgram's view: code, heap, stack
Virtual ≠ physicalTranslation on every access
GoalsTransparency, efficiency, protection
Next mechanismsBase/bounds, paging, TLB

Previous: Memory Virtualization Dialogue

Next: Address Translation — base/bounds, dynamic relocation, and the MMU.

Further Reading​