プロセス生成の内部（fork/clone/vfork/exec）

プロセス生成は「複製」と「置換」の二段構え

UNIX 系でプログラムを起動する典型は fork() で自分を複製し、子側で exec() して別プログラムに化ける、という二段構えです。なぜ「複製してから置換」という一見無駄な手順を踏むのか。fork と exec を分離しておくと、両者の間でファイルディスクリプタの差し替えやリダイレクトなど、子の実行環境を親が自由に整えられるからです。シェルのパイプやリダイレクトはこの隙間で実現されています。

本稿の主役は、この複製が 巨大プロセスでも一瞬で終わる からくりです。鍵は「アドレス空間を本当にコピーしない」こと。前提としてプロセスのアドレス空間とコピーオンライト（CoW）を押さえておくと理解が早まります。

fork の内部：ページテーブルだけを複製する

fork がやることは、直感に反して メモリのコピーではありません。実体（物理ページ）はそのまま、ページテーブルだけを複製 し、親子の全ての書き込み可能ページを 読み取り専用 に落とします。

1. 子の task_struct（プロセス記述子）を確保し、親の多くのフィールドを引き継ぐ
2. 親のページテーブルを走査し、子用に同じ物理ページを指すエントリを作る
3. 書き込み可能だったページは、親子双方 のエントリを read-only かつ CoW 印付きにする
4. 各物理ページの参照カウントを増やす（複数プロセスが共有中だと記録する）

この時点でコピーされたのは管理構造（ページテーブル）だけで、データ本体は1バイトも複製されていません。だから 10 GB のプロセスでも fork はミリ秒で返ります。

fork 直後（共有・read-only）:
  親 PTE ─┐
          ├─▶ [物理ページ X]（rw→ro, CoW印）  refcount=2
  子 PTE ─┘

子が書き込んだ瞬間（ページフォルト→CoW）:
  親 PTE ───▶ [物理ページ X]（refcountが1に戻れば rw へ復帰）
  子 PTE ───▶ [物理ページ X' のコピー]（rw）

実際にどちらかが書き込むと、read-only ページへの書き込みなので CPU が ページフォルト を起こし、カーネルがそのページだけ複製して書き込み側に専用ページを与えます。詳細はデマンドページングとページフォルトと同じ機構です。

clone：fork も pthread も同じ一つの入口

Linux では fork・vfork・pthread_create はそれぞれ別の仕組みではなく、すべて clone()（内部的には kernel_clone）という1つのシステムコールのラッパー です。違いは「どのリソースを親と共有するか」を指定するフラグだけです。プロセスとスレッドの区別が Linux では連続的になる理由がここにあります（プロセスとスレッド）。

組み合わせを変えるだけで生成物の性質が変わります。フラグをほぼ立てなければ独立プロセス（=fork）、CLONE_VM | CLONE_FILES | CLONE_FS | CLONE_SIGHAND | CLONE_THREAD をまとめて立てれば、アドレス空間もファイルも共有する スレッド になります。「スレッドはアドレス空間を共有するプロセス」という説明は、この CLONE_VM の有無として実装に直接対応しています。

/* スレッド生成は概ねこのフラグ集合（実際は glibc が組み立てる） */
clone(fn, stack,
      CLONE_VM | CLONE_FS | CLONE_FILES |
      CLONE_SIGHAND | CLONE_THREAD,  /* mm/fd/シグナル/PIDを共有 */
      arg);

CLONE_VM を立てた場合はページテーブルの複製すら起きません。親子（=スレッド）が 同一の mm_struct を共有 し、参照カウントを増やすだけで済みます。コンテナを支える CLONE_NEWPID 等の名前空間フラグも同じ枠組みで、何を分離するかを選びます（名前空間と cgroups）。

vfork：CoW のコストすら惜しむ最適化

fork の CoW は速いとはいえ、ページテーブルの複製と read-only 化、そして直後に exec すれば全部捨てるという無駄が残ります。vfork はこれを極限まで削る最適化です。

vfork は アドレス空間を一切複製せず、親子が生のまま同じ mm_struct を共有 します（CLONE_VM | CLONE_VFORK）。その代わり、子が exec か _exit を呼ぶまで 親は強制的に休止 させられます。親子が同じメモリ・同じスタックを同時に走ると破壊し合うため、親を止めて衝突を防ぐわけです。

つまり vfork は「どうせ exec で捨てるなら、コピーも read-only 化もせず、親を止めて一瞬だけメモリを貸す」という割り切りです。直後に exec するという前提があるからこそ成立する最適化です。

exec：ページテーブルを丸ごと捨てて張り直す

exec は 新しいプロセスを作りません。呼び出したプロセスの中身を、指定した実行ファイルのイメージで 丸ごと置き換える 操作です。PID は変わらず、メモリの中身だけが入れ替わります。

カーネルが行うのは概ね次の流れです。

1. 実行ファイルのヘッダ（ELF など）を読み、フォーマットを判定する
2. 現在のアドレス空間（古い mm_struct、全マッピング）を 解体して破棄 する
3. 新しい空のアドレス空間を作り、ELF のセグメント（text/data 等）を ファイルからメモリマップ する
4. スタックを作り、引数 argv と環境変数 envp、補助ベクタを積む
5. エントリポイントへ制御を移す（実コードはデマンドページングで遅延ロード）

ここで重要なのは、exec が 古いアドレス空間を捨てる こと。だから fork 直後に exec すると、CoW で苦労して read-only 共有していたページも、結局フォルトを起こす前に全部破棄されます。vfork が「最初からコピーしない」と割り切れるのは、この破棄が確実だからです。

実行ファイルのコード本体は exec の瞬間に全部読み込まれるのではなく、ファイルとして mmap され、実際に実行されたページから デマンドページング で順次ロードされます。これにより、使われない関数のコードはディスクから読まれずに済みます。

まとめ