Copy-on-Write and Lazy Allocation

Introduction

When a process creates a child using fork(), the child gets its own process identity and address-space view. A simple implementation could copy the parent’s entire memory immediately, but that can waste a lot of work.

Copy-on-Write and lazy allocation avoid this kind of unnecessary cost. Copy-on-Write delays copying until a write happens, while lazy allocation delays physical page allocation until a page is first touched.

Copy-on-Write

Copy-on-Write, or COW, is a virtual memory technique where parent and child initially share the same physical pages after fork().

Instead of copying every page immediately, the OS maps both processes to the same frames and marks those shared pages as read-only and COW-protected. Reads can continue normally. A write attempt triggers a page fault so the OS can create a private copy.

This is especially useful when the child soon calls exec(), because exec() replaces the child’s address space. Copying the parent’s entire memory before that would often be wasted work.

How Copy-on-Write Works

The COW flow is:

Child is created: fork() creates a child process with its own address-space view.
Pages are shared: Parent and child page tables point to the same physical frames.
Pages are protected: Shared pages are marked read-only and tagged as COW.
Reads continue: Either process can read the shared page.
Write causes a fault: A write attempt raises a protection page fault.
OS copies one page: The OS allocates a new frame and copies only the page being written.
PTE is updated: The writer’s page-table entry points to the new writable copy.
Instruction restarts: The write is retried and succeeds on the private page.

Only the page involved in the write is copied. Other shared pages can remain shared.

Copy-on-Write and How it Works

COW Savings Example

Suppose a parent process has 1000 pages. A child is created using fork(), writes only 3 pages, and then calls exec(). Without COW, the OS copies all 1000 pages at fork() time. With COW, the OS copies only the 3 pages that are actually written.

This is the main benefit of COW: physical copying happens only when modification actually requires a private copy.

Lazy Allocation

Lazy allocation delays physical memory allocation until a virtual page is actually used. A process may request a large heap or mapped region, but it may not touch every page in that range. With a naive approach, the OS would allocate and zero-fill physical frames for the whole range immediately.

Lazy allocation does something smarter. The process receives a valid virtual range, but physical frames are assigned only when individual pages are first touched.

How Lazy Allocation Works

The lazy allocation flow is:

Process requests memory: This may happen through mechanisms such as malloc, brk, sbrk, or mmap.
OS reserves virtual range: The address-space metadata is updated.
No frame is allocated yet: Physical memory is not consumed for every page upfront.
Process touches a page: The first access reaches a page with no physical frame.
Page fault occurs: The OS gets control.
OS validates the address: It checks that the address belongs to a valid reserved range.
Frame is allocated: A physical frame is obtained and usually zero-filled.
PTE is updated: The page becomes present and accessible.
Instruction restarts: The original access succeeds.

Pages that are never touched never consume physical frames.

Lazy Allocation and How it Works

COW vs Lazy Allocation

Aspect	Copy-on-Write	Lazy Allocation
Main purpose	Avoid premature copying	Avoid premature physical allocation
Common trigger	`fork()` sharing parent and child pages	Heap growth, stack growth, or mapped ranges
Initial state	Existing page is shared read-only	Virtual range exists without physical frame
Fault cause	Write to a shared COW page	First access to an unallocated page
OS action	Copy old page into a new frame	Allocate and zero-fill a new frame

The key difference is simple: COW copies an existing page, while lazy allocation creates a new page on demand.

Shared Page-Fault Idea

Both techniques use page faults as a controlled signal to the OS. A compact handler idea is:

COW page + write access: Create a new physical frame, copy the shared page into it, update the writer's page-table entry, and restart the instruction.
Lazy-allocated page: Allocate a new frame, fill it with zeros, update the page-table entry, and restart the instruction.
Invalid access: If the fault does not match either case, treat it as an invalid memory access and signal or terminate the process.

The page fault is not automatically an error. It can be the mechanism that lets the OS delay work until the exact moment it is needed.

Summary

Copy-on-Write shares physical pages first and creates a private copy only when a process writes to a shared COW page. It saves memory and copying work, especially after fork().

Lazy allocation reserves virtual address space first and allocates a physical frame only when a page is touched. Both techniques rely on page faults to delay unnecessary work while still preserving correct process isolation.