This trace follows the actual state transitions behind the companion Virtual Memory and the Page-Fault Path. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Look up the translation
Virtual memory lets each process use an address space that is translated through page tables and hardware translation caches. Pages provide the unit for mapping, protection, and often movement between RAM and storage. This abstraction supports isolation and flexible placement, but translations and misses have real costs.
Step 2: Walk page tables on a miss
On a memory access, the processor first uses a translation lookaside buffer when possible. If translation is absent, hardware or the kernel walks page tables. If the mapping is valid but not resident, a page fault transfers control to the kernel, which may allocate a page, load data, or reject an invalid access.
Step 3: Raise a fault if needed
A valid but nonresident mapping can fault into the kernel, which may load or allocate a page and then resume the instruction; an invalid access is rejected instead.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Resolve mapping or reject access
A page fault is not always an error: demand-zero allocation and copy-on-write can be handled transparently. A major fault that requires storage I/O is much slower than a minor fault resolved without disk access. Poor locality can cause repeated faults and thrashing.
Step 5: Retry the original instruction
After a process forks, explain why the parent and child may initially share physical pages yet observe independent writes. Identify the fault mechanism that enables this behavior.
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.