process isolation

Picture an apartment block where each tenant lives in a fully sealed unit: they cannot see into, walk into, or accidentally damage anyone else's home, and they cannot tamper with the building's own machinery in the basement. Even if one tenant's apartment catches fire, the others are unharmed. Process isolation is this guarantee for running programs: each process behaves as though it owns the machine, unable to read, corrupt, or crash any other process — or the operating system.

Concretely, isolation is achieved by giving each process its own page table, hence its own private virtual address space. Because the same virtual address in two processes maps to different physical frames (or to none), one process literally has no way to name another's memory — there is no virtual address it can form that translates into a neighbour's frame. The protection bits add a second layer, and the user/kernel privilege boundary keeps user code from touching kernel pages. On a context switch, the OS swaps the active page table (and may flush or tag the TLB), instantly changing which physical memory the running process can reach.

Why it matters: isolation is arguably the single most important thing virtual memory buys us. It is what lets a modern machine run untrusted programs side by side, contain bugs so one crash does not take down the system, and enforce security boundaries between users and applications. The honest nuance: isolation is only as strong as the hardware and OS that implement it — sharing is still possible deliberately (shared libraries, memory-mapped files, shared-memory regions map the same frame into multiple page tables), and microarchitectural side channels like Spectre and Meltdown showed that speculative execution can leak across boundaries the page tables were supposed to seal. Logical isolation does not automatically imply timing isolation.