Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
A fork() system call clones a child process from the running process. The two processes are identical except for their PID.
Naturally, if the processes are just reading from their heaps rather than writing to it, copying the heap would be a huge waste of memory.
Is the entire process heap copied? Is it optimized in a way that only writing triggers a heap copy?
The Linux kernel does implement Copy-on-Write when fork() is called. When the syscall is executed, the pages that the parent and child share are marked read-only.
If a write is performed on the read-only page, it is then copied, as the memory is no longer identical between the two processes. Therefore, if only read-operations are being performed, the pages will not be copied at all.
fork() call.
Oct 20, 2014 at 12:55
/proc/self/pagemap to determine the virtual address to physical page mapping for the purposed of the test. As I expected, if the grand-child and only the grand-child writes the shared page, then the parent and original child continue to share it. Only the grand-child ends up with a private copy.
The entirety of fork() is implemented using mmap / copy on write.
This not only affects the heap, but also shared libraries, stack, BSS areas.
Which, incidentally, means that fork is a extremely lightweight operation, until the resulting 2 processes (parent and child) actually start writing to memory ranges. This feature is a major contributor to the lethality of fork-bombs - you end up with way too many processes before kernel gets overloaded with page replication and differentiation.
You'll be hard-pressed to find in a modern OS an example of an operation where kernel performs a hard copy (device drivers being the exception) - it's just far, far easier and more efficient to employ VM functionality.
Even execve() is essentially "please mmap the binary / ld.so / whatnot, followed by execute" - and the VM handles the actual loading of the process to RAM and execution. Local uninitialized variables end up being mmaped from a 'zero-page' - special read-only copy-on-write page containing zeroes, local initialized variables end up being mmaped (copy-on-write, again) from the binary file itself, etc.
fork() used to copy the entire thing, so it wasn't always as lightweight as it is now. That's the reason for the existence of the vfork() system call which, nowadays, is largely useless and the speedup it provides is negligible.
Linux does Copy-on-Write. As fork creates a new process, the allocated pages are marked as readonly and shared between the parent and child. When either of them tries to modify a page, a page fault is generated resulting in copying the page and adjusting the page table appropriately.
