Chapter 23 — The unification: one table, every language, every payoff

The 30-second version. Twenty-two chapters ago, memory was a mystery; now it is a design space with named axes. Every language is a point in that space, chosen under constraints you can reconstruct. This chapter compresses the whole module into one comparison table, traces the connections forward into every queued module, and turns the knowledge into a working toolkit: the profilers, the flags, the practice path, and the questions that separate people who have this module from people who don't.

The four questions, one last time

Every language's memory model is its answers to four questions — you can now interview any language in four sentences:

1. What is a value? (unboxed bytes / boxed header+payload / tagged word — Chapter 06)
2. Who owns it? (the programmer / the scope / the last owner / the collector / nobody, it's static — Chapters 08-18)
3. Who frees it, and when? (explicitly / at scope exit / on drop / tracing / refcount / never — the whole Part II story)
4. What is promised about safety? (nothing / compile-time aliasing guarantees / runtime bounds checks / managed + unsafe edges — Chapters 08, 10, 21)

The grand table

Read a row, then a column — the table is both a reference and a map of design trade-offs spanning sixty years:

\* 64-bit, order-of-magnitude, platform-per-chapter caveats apply — every chapter states its exact numbers.

Three columns deserve a second read. Per-int cost: the 4→28-byte spread between C and Python is the entire "interpreted vs compiled" performance conversation in one number — it is representation (Chapter 06), not magic. Where freed bytes go: "never" (COBOL/Fortran) through "free-lists" (C world) to "copied and compacted" (GC world) — that axis is the fragmentation story of Chapter 05. Killer detail: each language's most distinctive memory fact, the one that identifies a practitioner who has actually been inside.

The derivation web: how the models descend from the machine

The module's spine, redrawn as one lineage:

silicon (ch01) → hierarchy (ch02) → virtual memory (ch03)
        │                                    │
   stack for nested lifetimes (ch04)    heap for everything else (ch05)
        │                                    │
        └────────── object layout (ch06) ────┘
                         │
                assembly ground truth (ch07)
                         │
   ┌──────────┬─────────┴──────┬──────────────┬─────────────┐
   manual      RAII       ownership      GC-family     refcount-family
   (C ch08)   (C++ ch09) (Rust ch10)  (Go/Java/C#/JS) (Python/Swift)
   └──── static family: COBOL/Fortran — no heap at all (ch17, ch18)
                         │
       allocators under everything (ch19) → hardware memory model (ch20)
                         │
        failure = security surface (ch21) + platform economics (ch22)

Every arrow is a forced move, not a fashion: GC exists because tracing beats refcount cycles (Chapter 14); compaction exists only where pointers are enumerable (Chapters 05, 12); ownership exists because compile-time is the only time you get safety for free (Chapter 10); mobile killing exists because swap can't (Chapter 22). If you can redraw this figure from memory, the field is yours.

The toolbox: see every model with its own eyes

The labs across the module, condensed into one cheat-sheet:

The meta-lesson: every memory question has an instrument. Teams that debug by staring at code are choosing blindness in a field where the truth is one command away.

How to practice (the path that makes it permanent)

Reading fades; building stays. Ranked by leverage:

1. Write a bump allocator (15 lines — Chapter 19). Then a pool allocator. Then a size-class free-list. You will never again find allocators mysterious, and Chapters 11-15's runtime internals become your design decisions.
2. Write a toy tracing GC in C or Rust: 2 semispaces, 512 objects, one root array, Cheney's scan (Chapter 12's diagram is the whole algorithm). You have now built what JVM/V8/ART run daily — and Chapter 15's forwarding-pointer map word will click forever.
3. Refcount with a cycle detector: Python's algorithm, 100 lines (Chapter 14's gc_refs subtraction). Watch it find the cycle your manual refcounts leaked.
4. Break each thing once: overflow a canary, double-free into tcache, false- share a counter, race a data-race litmus, leak a closure over a DOM node — each in a sandbox, each observed with its instrument (Chapter 21's defensive labs). Security understanding at this level is just memory-model knowledge pointed the other way.
5. Read one real crash per week with gdb + the frame grammar (Chapters 04, 07). In a quarter you will be the person on the team who reads core dumps.

The forward connections: why this was module 01

Every queued module is this module wearing another costume:

• Module 02 (memory security) — Chapter 21 is its first act: every exploit is a chapter 04-06 layout fact plus a chapter 19 metadata fact.
• Module 03 (software bugs) — the memory bug families are Chapters 05, 08, 20's failure modes; the race family is Chapter 20.
• Module 04 (decompilation & RE) — Chapter 07's grammar, industrialized: prologues, vtables, sret, calling conventions are how binaries are read.
• Module 05/06 (Android/iOS internals) — Chapter 22 in full: zygote COW, ART's collector, Jetsam's bands, the compressor.
• Module 07 (desktop OS internals) — Chapter 03's page tables, Chapter 19's slab, three times over.
• Module 08 (COBOL & mainframe) — Chapter 17 deepened: storage dumps, CICS, AMODE, the fixed-record world.
• Module 09 (concurrency & distributed) — Chapter 20's happens-before scaled to networks; CRDTs are copy-on-write's distributed grandchild.
• Module 10 (compilers) — the machine that manufactures Chapters 06-07's layouts: register allocation, escape analysis, barrier insertion.
• Module 11 (databases) — Chapter 02's hierarchy at disk scale; Chapter 03's COW as MVCC; Chapter 05's page management as buffer pools.
• Module 12 (GPU/AI) — Chapter 01-02's economics rebuilt in HBM and SMEM; coalescing is cache-line arithmetic for a different wire.
• Module 13 (networking) — the buffers moved: Chapter 05's allocator questions, the Chapter 04 stack discipline, and Chapter 02's hierarchy now measured in wire time — a packet is memory in motion.
• Module 14 (file systems) — the heap that outlives the process: Chapter 19's allocators persisted to disk, Chapter 03's COW as Btrfs/ZFS snapshots.
• Module 15 (virtualization & cloud) — Chapter 03 sold as a product: the second page table, ballooning as GC for VMs, oversubscription as the bank run model.
• Module 16 (browsers) — Chapter 05-06's object graphs at page scale: the DOM heap, two collectors, one wrapper problem, and the 16.6 ms budget.
• Module 17 (hardware design) — Chapters 01-03 derived from transistors: the cache you measured, built in RTL; the power equation behind every "why is it slow" this module ever answered.
• Module 18 (cryptography) — the one field where Chapter 02's cache line is a breach and Chapter 05's heap over-read cost a billion dollars: memory discipline as the security boundary.
• Module 19 (PL theory) — this module's table, theorized: every language row is a point on the guarantees frontier, every collector a proof search, every rule a theorem you already use.
• Module 20 (embedded) — this module with the safety net removed: one address space, the stack pointer in a file, the memory map in silicon.
• Module 21 (formal verification) — the machines that prove what this module's languages only promise: kernels, compilers, and the borrow checker itself, as theorems.
• Module 22 (ML systems) — the unification at datacenter scale: the tensor as the 17th object model, sharding as the 175-billion-object heap, the KV cache as virtual memory for tokens.

That is the entire program thesis in one paragraph: memory is the root layer of computer science, and every field is a branch that forgot it has roots.

What insiders know (the module-sized version)

• The interview layer: "stack vs heap," "what does &x compile to," "why is a Python int 28 bytes," "why does freeing not shrink RSS," "what does volatile/atomic actually order," "why can't malloc compact" — this module is the answer key, with numbers.
• The debugging layer: crash triage (04/07/21), leak-vs-fragmentation-vs- retention (05/19/14/15), GC forensics (11/12/13/15/22), cache pathology (02), race detection (20) — the five recurring memory tickets in every production system.
• The design layer: lifetime classes (05), representation choice (06), allocation-rate discipline (11/12/22), layout budgeting (02/06), safety economics (10/21) — the decisions senior engineers are actually paid to make.
• The one-line summaries people remember chapters by: locals are free because frames are batch; malloc costs metadata because free forgot the size; GC exists because cycles beat refcounts; compaction needs enumerable pointers; ownership is aliasing×mutation at compile time; the canary sits between your bug and the return address; mobile OSes kill because swap can't; COBOL never allocates so never leaks; everything above silicon is a cache.

Quiz — the final eight (cross-module synthesis)

1. Order these by memory-safety strength for engine-level code, and justify: C, Rust (safe), Java, C++ with RAII + sanitizers in CI.
2. A polyglot service leaks in production: Rust core, Python orchestration, JS frontend graphs, a C FFI codec. Describe your triage sequence across the modules' tools.
3. Why does the same numeric workload cost ~7x more memory in Python than C? Answer with representation, not adjectives.
4. fork() is fast, zygote app-launch is fast, JVM -Xmx reserves huge virtual space, and mmap'd files cost ~nothing resident — name the single Chapter 03 mechanism doing all four.
5. An exploit needs: a heap-adjacent metadata fact (ch19), an address-layout fact (ch03), a frame-layout fact (ch04), and a representation fact (ch06). Name one concrete fact of each and the attack phase it serves.
6. Why do Go, Java, C#, V8, and ART all reach the same allocator design (bump + size classes + per-thread caches) despite five different GCs? Derive it from Chapters 05+19+12.
7. One sentence each: why does (a) Python's gc module exist, (b) Swift's weak references zero themselves while Rust's cannot, (c) COBOL forbid recursion (pre-2002), (d) Android kill apps where desktops swap?
8. You get one hour to teach a junior "why is our p99 slow under load." Build the lesson plan from this module's chapters.