Learn the vocabulary of deferring a memory page's copy until the moment a process actually writes to it.
0 / 5 completed
1 / 5
At standup, a dev mentions two processes sharing the exact same underlying memory pages after a fork, with an actual private copy of a page only made the moment either process tries to write to it. What is this technique called?
Copy-on-write lets two processes share the exact same physical memory pages after a fork, deferring the actual cost of copying a page until the moment either process tries to write to it, at which point only that one page is duplicated for the writer. A memory leak is an unrelated concept about memory never being reclaimed. This deferred copying is exactly what makes forking a large process cheap, since most pages are often never written to before the child process replaces its memory entirely with a new program.
2 / 5
During a design review, the team relies on copy-on-write specifically so that forking a large parent process doesn't require immediately duplicating every one of its memory pages up front. Which capability does this provide?
Copy-on-write provides a fast, cheap fork, since only the pages that are actually written to afterward ever need a private copy made, while every untouched page keeps being shared directly between parent and child at no extra memory cost. Duplicating every single page immediately would make forking a large process slow and memory-hungry regardless of how much of that memory the child process actually ends up modifying. This deferred-copy behavior is exactly why fork is cheap enough to be used routinely for spawning new processes.
3 / 5
In a code review, a dev notices a data structure is duplicated in full every time it's passed to a function that might modify it, even though the vast majority of those calls never actually change anything. What does this represent?
This is a missed opportunity for copy-on-write, since sharing the same underlying structure across calls and only duplicating it the moment an actual write occurs would avoid the wasted duplication cost on every call that never modifies anything. A cache eviction policy is an unrelated concept about discarded cache entries. This eager-copy pattern is exactly the kind of unnecessary overhead copy-on-write is designed to eliminate, by shifting the duplication cost from every call to only the calls that truly need it.
4 / 5
An incident report shows a service's memory usage and latency both spiked under load because a large shared configuration object was being fully duplicated on every request, even though only a tiny fraction of requests ever actually modified it. What practice would prevent this?
Sharing the configuration object across requests and applying copy-on-write, so a private copy is only made for the rare request that actually writes to it, eliminates the wasted duplication cost on the overwhelming majority of requests that never modify it, which is exactly the fix for the spike described in this incident. Continuing to fully duplicate it on every request regardless of actual modification is exactly what caused the memory and latency spike under load. This deferred-copy pattern is the standard fix for any structure that's read far more often than it's written.
5 / 5
During a PR review, a teammate asks why the team relies on copy-on-write instead of simply always sharing the same structure directly across every process or request with no copying at all. What is the reasoning?
Always sharing a structure directly with no copying at all risks one writer's change silently corrupting what every other reader or process still expects to see, since they have no idea the underlying data changed out from under them. A private copy is therefore still genuinely needed at the exact moment a write happens, copy-on-write just defers paying that cost until it's actually necessary rather than paying it eagerly for every reader up front. The tradeoff is the small bookkeeping overhead of tracking which pages are still shared and which have already been privately copied.