§13.1–13.3Early Systems … The Address Space

Early on, building systems was easy — users didn’t expect much. It’s those darned users, with their demands of “ease of use” and “high performance,” who caused all these headaches. (Thank one, next time you see one.) This chapter earns the memory arc’s vocabulary: what an address space actually is, and why it must be an illusion.

13.1 Early Systems

From memory’s perspective, early machines provided no abstraction at all:

13.2 Multiprogramming and Time Sharing

Machines cost hundreds of thousands of dollars, so people shared them: first multiprogramming (switch processes on I/O; raise utilization), then — because programmers were tired of agonizing batch debug cycles — time sharing and interactivity.

One crude implementation: give the running process all of memory (as in Figure 13.1), and on every switch save its entire memory to disk and load the next process’s. Correct — and brutally slow, ever slower as memories grow. Registers are cheap to save; megabytes are not. The fix that stuck: leave processes resident in memory and switch between them:

Residency changed the stakes. With multiple programs in memory at once, protection became critical: nobody should read — or worse, write — another process’s memory.

13.3 The Address Space

For the pesky users, the OS needs an easy-to-use abstraction of physical memory: the address space — the running program’s view of memory. It contains all the memory state of the program: the code code segment The address-space region holding the program's instructions — static in size, conventionally placed at the top (low addresses). defined in ch. 13 — open in glossary (instructions), the heap heap Memory region for explicitly requested dynamic allocations — malloc() and free() in C. defined in ch. 4 — open in glossary (malloc/new data), and the stack stack Memory region for function parameters, local variables, and return addresses; allocated by the OS at process creation. defined in ch. 4 — open in glossary (call chain, locals, parameters) — plus odds and ends like statically-initialized variables:

Code sits at the top (static, never grows). Heap and stack take the two ends of the remaining space and grow toward each other — that’s the convention that lets both expand freely (until threads ruin it, but that’s Part II’s problem).

Now the essential trick. The address space is the abstraction the OS provides — the program is not really at physical 0–16KB. Look back at Figure 13.2: process A believes it starts at address 0, but it lives at 320KB. When A loads from address 0, something must quietly redirect that load:

When the OS pulls this off, it is virtualizing memory: the program thinks it’s loaded at some address (say 0) into a potentially huge space (32 or 64 bits’ worth); reality differs, quietly. The goals that “with style” implies — and the tools you have as a user to peek at your own virtual space — are next.