Mateusz Pachulski

Android from the foundation · Puzzle 11 of 16

Sharing memory without sharing mistakes

If every app were a full copy of Zygote, memory would run out fast. The kernel makes the copies share, and copies only what changes.

The problem

In puzzle 10, every app process started as a copy of Zygote. But Zygote holds a lot: ART and the whole framework. Twenty apps, twenty full copies? The phone would run out of memory. And yet each app must be able to change its own data without changing anyone else's.

See it

Zygote's memory is made of pages; forked apps share them; when one app writes to a page, only that page is copied for it + many more apps, same pages kernel Zygote pages your app another app shared writes: own copy

  1. The kernel hands out memory in small blocks of the same size: pages. Zygote's ART and framework fill many of them.

    Step 1 of 4

  2. After a fork, the new processes don't get their own copies: they share Zygote's pages instead of copying them. Predict: what if your app changes one?

    Step 2 of 4

  3. Then, and only then, the kernel copies that one page for your app. The others keep the original: copy-on-write.

    Step 3 of 4

  4. Most pages are never changed, so they stay shared: twenty apps cost little more than one framework.

    Step 4 of 4

Save this diagram as a GIF

The building block

The kernel hands out memory in small fixed-size blocks called pages.

When a process forks, the kernel doesn't copy the pages. The original (Zygote) and the new process share them. Only when one of them writes to a page, that is, changes it, does the kernel make a private copy of that one page for the writer: that's copy-on-write. Everything nobody changes stays shared, so twenty apps cost little more than one framework.

That doesn't break puzzle 0's rule. The shared pages hold only what came from Zygote, the same ART and framework every app has: never one app's own data. Nobody writes to a shared page itself: a write goes to a private copy. So no process can see or change another's own data.

The analogy

Every new house uses the show house's furniture. Repaint a chair, and only then do you get your own copy of that chair. The other houses keep the original.

Check yourself

Twenty apps are running. How many copies of the framework's pages are in memory?

Not quite. Forking shares pages; it doesn't duplicate them.

Right. Untouched pages stay shared after a fork.

Your app changes one shared page. What happens in the other apps?

Right. Only the writer gets a copy; everyone else keeps the original.

Not quite. Writing is allowed; it just goes into a private copy.

Not quite. That's exactly what copy-on-write prevents: you write into your own copy.

Why doesn't the kernel copy every page at fork?

Not quite. Pages can be copied, and are, when written. Doing it up front would waste memory.

Right. Copy only what changes.

Sources

What you now know

Memory comes in pages. After a fork, parent and child share every page; a page is copied only when one of them writes to it: copy-on-write.