Paging, segmentation, and page faults

Lesson 6 introduced pages — fixed-size blocks (commonly 4KB) that are the unit virtual memory is managed in. Each process has a page table mapping its virtual pages to physical memory locations (frames). The MMU consults this table on every memory access to perform the translation. Because pages are a fixed size, the OS can freely place any virtual page in any available physical frame — nothing needs to be contiguous, which makes memory allocation and reuse far simpler than if every process needed one large, unbroken block of physical RAM.

Segmentation divides memory into variable-sized logical units instead — a code segment, a data segment, a stack segment — each representing a meaningful part of the program rather than an arbitrary fixed-size chunk. Older systems used segmentation exclusively; many practically important distinctions from it (separating a program's code from its stack, for instance) live on conceptually in how a process's address space is organized (lesson 3's stack/heap/code/data regions), even though most modern systems primarily rely on paging for the actual memory-management mechanics, sometimes combined with segmentation for finer-grained protection.

A page fault happens when a process accesses a virtual address whose page isn't currently mapped to physical memory. The CPU traps into the kernel, which figures out what to do next:

A minor page fault happens for entirely normal reasons — for instance, the first time a process touches a newly-allocated page that the OS hasn't actually backed with a physical frame yet (deferring the real work until it's needed, called lazy allocation). These are fast and expected, happening constantly during normal program execution without any performance concern.

A major page fault is slower and more consequential — the needed page has to be read from disk (because it was swapped out, or because it's part of a file being memory-mapped). A program suddenly full of major page faults is a strong, specific signal that it's actively swapping — see lesson 6's note on why that dramatically slows a system down.

When the kernel determines an accessed address isn't valid at all — reading through a null or corrupted pointer, writing past the end of an array into memory the process was never granted — that's an illegal access, and the OS terminates the process rather than letting it continue touching memory it has no legitimate claim to. This is the process isolation mechanism from lesson 2 actively enforcing itself, in real time, against a specific bad memory access.