The connections map

One root, twenty-two trees, 1129 cross-references: every number in this table is a place one chapter reached into another and said you already know this — use it here. Computed live from the chapter markdown at build time.

The dependency matrix

Row = the citing module, column = the cited module. Module 01 is the root: every module reaches into it (column 01), and — after the connection retrofit — it reaches forward into all twenty-one trees (row 01). Darker cells are stronger ties.

→ cites 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22
01 Memory models of programming languages 7 3 1 1 1 5 2 1 1 1 2 2 3 4 5 12 4 3 7
02 Memory security & exploitation 43 3 2
03 Software bugs 32 9 1 1 2 2 10
04 Decompilation & reverse engineering 19 7 2 1 1 1 2
05 Android internals 25 3 4 5 3 1 1 1
06 iOS internals 31 4 3 4 13 4 2
07 Desktop OS internals 27 10 5 6 4 19 3 4
08 COBOL & the mainframe world 30 8 3
09 Concurrency & distributed memory 24 11 3 2 2 1
10 Compilers & runtime internals 33 11 14 7 1
11 Database storage engines 27 2 4 1 3
12 GPU & AI accelerator memory 26 2 4 3 2 2
13 Networking internals 16 5 3 11 2
14 File systems & storage 23 22 3
15 Virtualization, containers & the cloud 27 7 4 1 2 8 5
16 Browser engine internals 24 5 6 8 8
17 Digital hardware 26 4 9 2
18 Cryptography internals 12 6 1 3 1 4 4
19 PL theory & type systems 30 3 1 1 2 6 3
20 Embedded & firmware 22 4 5 4 2 1 8 11 2 3 3 2 7 4 5
21 Formal verification 10 3 1 1 2 3 4 6 29
22 ML systems & training infrastructure 36 3 2 2 4 11 2 2 2 1 3

The strongest ties

The pairs that carry the most cross-references — where two fields turn out to be the same idea wearing different clothes.

modulecitesrefs
02 Memory security & exploitation→01 Memory models of programming languages43
22 ML systems & training infrastructure→01 Memory models of programming languages36
10 Compilers & runtime internals→01 Memory models of programming languages33
03 Software bugs: the taxonomy of failure→01 Memory models of programming languages32
06 iOS internals→01 Memory models of programming languages31
19 PL theory & type systems→01 Memory models of programming languages30
08 COBOL & the mainframe world→01 Memory models of programming languages30
21 Formal verification→19 PL theory & type systems29
07 Desktop OS internals→01 Memory models of programming languages27
15 Virtualization, containers & the cloud→01 Memory models of programming languages27
11 Database storage engines→01 Memory models of programming languages27
12 GPU & AI accelerator memory→01 Memory models of programming languages26

The load-bearing chapters

The chapters the rest of the program leans on hardest. These are the pages to read twice: almost every other chapter assumes them.

the load-bearing chaptersinbound refs
m01 ch03 — Virtual memory: the grand illusion139
m01 ch02 — The hierarchy: latency is the tax, locality is the loophole61
m01 ch04 — The stack: the shape of call lifetimes56
m01 ch05 — The heap: the everything-else machine46
m01 ch19 — Allocators: the machinery under malloc38
m01 ch20 — The hardware memory model: why cores disagree about memory31
m03 ch02 — The memory-bug family27
m01 ch12 — Java: the generational heap of the JVM26
m01 ch14 — Python: everything is a PyObject22
m19 ch03 — Memory safety as a theorem19
m02 ch06 — The mitigation ladder18
m01 ch06 — Object layout: what a "value" really looks like in RAM18
m01 ch01 — Memory from silicon17
m06 ch02 — Jetsam & the compressor15

How to read the map

Start anywhere: pick a module you care about, read its chapters, and follow its citations backward to the roots (they nearly all end at module 01, chapter 03 or chapter 05). Then follow them forward: the same page you just read is the prerequisite for three modules you have not opened yet. That is the whole design of this program: one root layer, twenty-two fields, and a thousand doors between them.