copy-on-write
Imagine two roommates who both want their own copy of the same long shopping list. Photocopying it immediately is wasteful if neither plans to change it — they could just share the one list and read from it. So they share, and they make a private copy only at the moment one of them actually wants to scribble a change. Until someone writes, one shared list serves both; the copy happens lazily, on the first write. Copy-on-write applies exactly this trick to pages of memory.
Concretely, when a process forks a child, the child gets a copy of the parent's address space. Copying every page eagerly would be slow and often pointless, since the child frequently just calls exec and replaces its memory anyway. Instead, copy-on-write lets parent and child share the same physical frames, all marked read-only in both page tables. As long as both only read, they happily share one copy. The moment either one tries to write to a shared page, the hardware traps (a protection fault); the OS then makes a private copy of just that one page for the writer, points the writer's page-table entry at the new frame with write permission restored, and lets the write proceed. Only the pages that are actually modified ever get duplicated; everything untouched stays shared.
Why it matters: copy-on-write makes fork cheap and fast, which matters because fork-then-exec is the standard way Unix-like systems launch new programs. Without it, every fork would have to duplicate the parent's entire memory only to throw it away an instant later. The same idea powers efficient snapshots, virtual-machine memory sharing, and copy-on-write file systems. The honest subtlety: copy-on-write only defers the cost, it does not eliminate it — a workload where parent and child both write heavily will trigger many copies and may end up no cheaper than copying up front, plus the per-fault trap overhead.
A process using 500 MB forks. Instead of duplicating 500 MB, the OS marks all pages read-only and shared. The child immediately calls exec, replacing its memory entirely — so almost none of those 500 MB were ever actually copied. Only the few pages the child wrote before exec needed duplication.
Pages are shared until written; only modified pages are ever duplicated.
Copy-on-write defers, not eliminates, the cost of copying. If both parent and child write to most pages, you pay the duplication anyway plus the overhead of a trap per first-write — so it is a win mainly for the common fork-then-exec or mostly-read-sharing patterns.