Memory that does not exist yet

Ask a program where its memory lives and it points at an address. Ask the machine the same question and the answer may be: nowhere yet.

That is not a bug. The address is virtual. It names a spot in this process's address space — not a particular RAM chip. Linux can give you the address first and supply real storage later, when you first touch it.

People often hear “virtual memory = disk as extra RAM.” That is one side effect. The useful idea is simpler:

Virtual memory is an indirection layer between the addresses a program uses and the physical frames the hardware can access.

This lesson walks that layer top to bottom. Terms are defined before they show up. You will get annotated terminals and a visual model of the address space. On macOS there is no /proc — use the macOS toggle where you see one.

By the end you should be able to say, in plain language: what a virtual address is, what a page fault does, why fork is cheap until someone writes, and why memory dashboards disagree.

1. An address is not a RAM chip

Suppose a program does:

ask for 1 GiB of memory
write one byte at the start

If that succeeds, the process owns a range of virtual addresses. It has not necessarily consumed 1 GiB of RAM. Linux may wait until each page is first touched before providing a physical frame.

Three different quantities (do not mix them):

• address space — ranges of virtual addresses the process is allowed to use
• resident memory — pages from those ranges currently backed by physical RAM
• committed / promised — what the system has said it should be able to provide if you eventually touch it (subject to overcommit policy)

A huge address range can hold almost no resident pages. A page can be resident and shared by a hundred processes. A malloc can succeed and a later write can still fail under memory pressure.

Pages (the unit of translation)

The CPU does not usually translate every byte alone. Memory is divided into fixed-size pages. On typical Linux x86-64 / arm64, a base page is 4 KiB.

Think of a virtual address as:

[ which page? ][ byte inside that page ]

Translation finds a physical frame for the page number. The offset inside the page stays the same.

You do not need the bit math yet. You need the habit: systems talk in pages.

2. Your process has a map of allowed regions

Linux records contiguous chunks of address space as VMAs — virtual memory areas. A VMA answers: “is this range allowed, and what is it for?”

Examples of what a VMA might say:

• readable / writable / executable
• anonymous (just zeros / heap) or backed by a file (your binary, a .so)
• private or shared
• stack, heap, code, library…

Empty gaps between VMAs are real. Touching a gap is illegal even if the machine has free RAM.

Checkpoint: an address is only meaningful if a VMA covers it. The map is policy — “you may use these ranges.” It is not yet the live translation the CPU uses on every load and store.

3. Two layers: the permit and the street address

Here is the part that usually goes too fast. Slow it down.

Your process has two related ideas, and they are not the same:

1. The permit (VMA) — “Is this virtual address in an allowed region?”
   If no → crash (SIGSEGV), even if the machine has free RAM.
2. The street address (PTE) — “Right now, which physical RAM frame backs this page — if any?”
   A page can be allowed (permit yes) and still have no frame yet (street address missing).

A page table is just the kernel’s book of those street addresses for pages that are in play. Each entry is a PTE (page-table entry). It can say:

• present or absent
• writable or read-only
• executable or not

The sentence that unlocks the rest of this lesson:

“Not present” does not mean “invalid.”

• Permit yes, PTE absent → often a page fault the kernel can repair
  (lazy allocation, first touch, copy-on-write, …)
• Permit no → illegal → usually SIGSEGV

Click around in the visual below. Hollow mapped pages are “allowed but not in RAM yet.” Dashed gaps are illegal. Filled pages already have a frame.

You can ignore the TLB for now (a cache of recent translations). Just remember: the CPU wants a present PTE; if it does not have one, it asks the kernel.

4. First touch: the page fault as a slow “yes”

When the CPU cannot finish a translation (or permissions disagree), it pauses the instruction and asks the kernel. That pause is a page fault.

The kernel checks the permit, then tries to fix the street address:

1. Is this address covered by a VMA?
2. Is this kind of access allowed (read / write / execute)?
3. Can we give it a frame (or fix permissions)?

If yes: install the PTE, return, and the CPU retries the exact same instruction. Your program usually does not see an error — the access just took longer.

If no: the kernel cannot repair it → signal.

Two common labels:

• Minor fault — fixed without waiting on disk (fresh zero page, or page already in the page cache)
• Major fault — must wait for storage I/O (cold file page)

“Minor” is not “harmless forever.” It only means “no disk wait this time.”

The visual plays the story. Underneath, the same demo is in Python and C++ (switch panes) — every step explained, not a cryptic blob.

Use anonymous mmap, not bytearray or value-initialized new char[N](). Those often touch pages while allocating, so “after alloc” and “after touch” can look identical. That does not disprove demand paging — it means the demo allocated eagerly.

Checkpoint: malloc / mmap often reserve. Touching pays. The payment mechanism is the page fault.

One caution: Linux may overcommit — promise more anonymous memory than it could hold all at once if everyone touched everything. A successful allocation is not a guarantee that every future write succeeds under pressure.

5. Where do the bytes come from? (mmap, cache, COW)

mmap creates a VMA (a permit). It does not mean “read the whole file into RAM now.”

• Anonymous mapping — no file. Pages start as zeros. Frames appear on touch. Heaps are often built this way.
• File-backed mapping — addresses correspond to file offsets. First touch may fill from the page cache (or from disk into that cache), then install a PTE.

Buffered read() and file-backed mmap() usually share the same page cache. Clean cache is “used” RAM that is often reclaimable — which is why staring only at free misleads.

Copy-on-write in one picture

For private mappings (and for memory after fork):

• Reads can share one physical frame among processes
• The first write copies that one page and points only the writer at the private copy

That is copy-on-write (COW). Not “copy the whole heap on fork.” The next block shows the three moments side by side — before fork, right after, and after one write — so you can see that only the touched page grows RAM.

Checkpoint: sharing until write is why fork is cheap — and why a child that dirties a huge inherited buffer suddenly costs RAM.

6. Why memory numbers disagree

Dashboards argue because they answer different questions:

• VSZ / VIRT — how much address space is mapped? (includes untouched)
• RSS — how much resident memory can this process reach?
  (shared pages counted fully in each process)
• PSS — what fair share of resident memory should we attribute here?
  (shared pages divided among mappers)
• Private / USS — what would likely free if only this process exited?

Summing RSS across processes double-counts shared libraries. That is the wrong question, not bad arithmetic. Hollow-vs-filled pages from earlier are the same idea: mapped ≠ resident.

Working set (short): residency changes over time. You can have 2 GiB resident and only actively need 100 MiB. Under pressure, cold clean file pages can be dropped and faulted back later.

7. A microVM adds another translation layer

Inside a guest, a process still uses guest virtual addresses. The guest kernel still has VMAs and page tables. Virtualisation adds a second step:

guest virtual address
        → guest page tables →
guest physical address
        → second-stage translation →
host physical frame

Same idea — an address at one layer, a translation to backing at the next — with a different owner for each fault. File that away for Firecracker. Today’s foundation does not change.

What to keep

1. A virtual address is not a physical location.
2. A VMA is the permit; a PTE is the current street address.
3. Absent PTE can be repairable; unmapped cannot.
4. A page fault is often how lazy memory works — not always a crash.
5. COW shares until write; only the written page becomes private.
6. VSZ ≠ RSS ≠ PSS — pick the number that matches your question.

Next: a pathname is not a file on disk — how names become inodes, pages, and blocks, and why a microVM root disk is a filesystem inside a file.