Memory management

The Executive named the Memory Manager as one of its core components — arguably the one whose decisions have the most day-to-day visible impact on performance. This chapter is the overview; the next four go one layer deeper into specific mechanisms: the VAD tree, paging and page faults, working sets and trimming, and pool & heap.

Virtual memory is not fake memory

A program never sees or works with physical RAM addresses directly. Instead, every process gets its own virtual address space — a private, logical address map the Memory Manager translates into real physical memory (or disk, when necessary) behind the scenes. This isn't a simplification made for programmer convenience — it's the mechanism underneath process isolation itself: because process A's virtual addresses are translated independently of process B's, there is no address A's code could use, accidentally or maliciously, to reach into B's memory. The isolation guaranteed by the ring 0/ring 3 boundary in System architecture is enforced, address by address, through exactly this translation.

What the Memory Manager is actually deciding, continuously

For every process, the Memory Manager is tracking and deciding:

• Which virtual ranges are reserved, committed, or free, and what each range's purpose and protection are — tracked in the VAD tree.
• Which committed pages are actually backed by physical RAM right now, versus which exist only as a promise, to be fetched or created on demand — the subject of paging and page faults.
• Which resident pages stay resident under memory pressure, and which get reclaimed first — working sets and trimming.
• How small, frequent allocations get served efficiently, both in the kernel and in user-mode applications — pool & heap.

A worked example: a browser with many tabs

Each browser tab process appears, from its own point of view, to have a large private virtual address space — often far larger than the machine's actual physical RAM. That's not a contradiction: the Memory Manager only backs with real physical pages whatever the process is actually using right now, and pages that were touched once and haven't been needed since can be evicted (potentially to the page file) and reconstructed later if referenced again. The virtual address space is a promise about addressing, not a guarantee that every byte of it occupies real RAM simultaneously.

A common mistake

Treating "virtual memory" as a euphemism for "not real, slower memory" misunderstands what the word "virtual" is doing there. It refers to address translation, not to the memory being fake or degraded — a page that's resident in physical RAM, accessed through its virtual address, runs at full hardware speed; the translation itself (handled by the CPU's memory-management unit, consulting page tables the Memory Manager maintains) is not a meaningful performance cost for ordinary code. The actual performance cost this level explores — paging to disk, working-set trimming — is a separate, specific consequence of memory pressure, not an inherent property of virtual addressing itself.

Where this connects

• Processes & threads is what owns each address space this chapter describes — memory management always happens in the context of a specific process.
• The Cache Manager works closely with the Memory Manager, using the same page-resident/page-evicted machinery to keep frequently accessed file data fast to reach.