末尾呼び出しとスタックフルvsスタックレス

並行実行単位を分ける2つの軸

「並行に走らせる単位」と一口に言っても、OSスレッド・グリーンスレッド・ファイバー・コルーチンと種類があります。これらの違いは、たった2つの軸で整理できます。第一はスケジューリングの主体、すなわち「次に何を走らせるかを誰が決めるか」。OS（カーネル）が決めるならプリエンプティブ、ランタイムやコード自身が中断点を選ぶなら協調的（cooperative）です。第二はスタックの持ち方、すなわち中断中の「実行位置とローカル変数」をどこに退避するか。専用スタックを丸ごと持つスタックフルか、関数1個ぶんの状態に畳むスタックレスかです。

この2軸が、メモリ消費・切り替えコスト・中断できる場所のすべてを規定します。以下、軸ごとに原理を押さえます。

OSスレッド：カーネルが運ぶ重い単位

OSスレッドは、カーネルがスケジュールする実行単位です。各スレッドは固定的なカーネルスタックと、ユーザー空間に数百KB〜数MBのスタック（Linuxの既定は8MB予約・遅延コミット）を持ちます。切り替え（コンテキストスイッチ）はカーネルへの特権モード遷移を伴い、レジスタ群の退避・復元に加え、別アドレス空間へ移るならTLB（アドレス変換キャッシュ）のフラッシュまで起き得ます。1回あたり数百ns〜数µsで、これが数万本となるとスケジューラのオーバーヘッドとメモリ予約が効いてきます。

利点は明快です。カーネルがプリエンプティブに時間を割り当てるので、1本がCPUを握り続けても他が飢えません。マルチコアへ真に並列に配置でき、ブロッキングなシステムコールを呼んでも他スレッドは止まりません。詳しい棲み分けは並行性モデルを参照してください。

グリーンスレッドとファイバー：ユーザー空間でスケジュールする

カーネルの重さを避けるため、ランタイム（ユーザー空間）が自前でスケジュールする軽量スレッドが生まれました。Goのgoroutine、Javaの仮想スレッド、Erlangのプロセスなどが代表です。歴史的に「グリーンスレッド」はユーザー空間スケジューラ上の軽量スレッドを指し、ファイバーはそのうち協調的に明示譲渡するものを指す語として使われます。

実装面では、少数のOSスレッド（キャリアスレッド）の上に多数の軽量スレッドを載せるM:Nモデルを取ります。ランタイムスケジューラが軽量スレッドをキャリアスレッドへ割り付け、中断時には別の軽量スレッドへ載せ替えます。この載せ替えはカーネルを通らないため、コンテキストスイッチが特権遷移を伴わず、OSスレッドより桁で安くなります。空いたキャリアスレッドが他のキューからタスクを奪う作業窃取スケジューラと組み合わせるのが定石です。

肝心なのは、これら軽量スレッドがスタックフルだという点です。goroutineは各自が独立したスタックを持ち、何段深い関数の中からでも中断・再開できます。だからGoでは普通の関数呼び出しがそのまま中断点になり得て、awaitのような印を全段に付ける必要がありません。

スタックフル vs スタックレス：何を退避するか

軽量実行単位の実装は、中断時に何を退避するかで2系統に分かれます。これが本記事の核心です。

スタックフルは、コルーチンごとに独立したスタックを丸ごと持ちます。中断とは「現在のレジスタ（特にスタックポインタとプログラムカウンタ）を退避し、別コルーチンのスタックへ切り替える」操作です。スタックがそのまま生き残るので、何段深い関数からでも中断でき、再開すれば全フレームがそっくり復元されます。代償は1本ぶんのスタック領域です。

スタックレスは、コルーチンを状態機械へコンパイル時変換します。中断点（await/yield）ごとに状態番号を振り、中断をまたいで生きるローカル変数だけをヒープの状態オブジェクトへ退避し、関数全体を「状態番号で続きへジャンプする1つのresume」に書き換えます。退避するのは関数1個ぶんの最小限なので極めて軽量です。ただし退避できるのはその関数の本体だけで、呼んだ先の関数の途中状態は畳めません。詳しい変換はasync/awaitの内部実装で扱っています。

関数の色（async汚染）が生じる理由

スタックレスの「呼び先の途中状態を畳めない」制約は、実コードで関数の色問題として現れます。普通の関数の途中で中断したくても、状態機械化はその関数自身をasyncにしないと適用できません。すると呼び出し元も結果をawaitせざるを得ず、asyncが呼び出し連鎖を上へ上へと伝播します。これが「同期関数から非同期関数を素直に呼べない（色が混ざらない）」現象の正体です。

スタックフルにはこの問題がありません。スタックを丸ごと退避できるので、どんな普通の関数の途中からでも譲れ、印は不要です。Goでnetパッケージの関数を呼ぶだけでブロックせず他のgoroutineへ切り替わるのは、ランタイムがスタックフルな中断を裏で行っているからです。

切り替えコストの大小と、選択の指針

3方式の切り替えコストは、関与する層の深さで決まります。OSスレッドはカーネルを介し特権遷移とスケジューラ実行を伴うため最も重い。スタックフルコルーチンはユーザー空間でレジスタとスタックポインタを差し替えるだけで、カーネルを通らないぶん桁で安い。スタックレスは状態機械のresume呼び出し、すなわちほぼ「関数呼び出し1回＋状態分岐」なので最軽量です。メモリも同順で、スレッドの数MB予約に対し、スタックフルは数KB、スタックレスは状態1個ぶんに収まります。

選択の指針は次のとおりです。

実際のランタイムは折衷です。Goは「M:Nのスタックフルgoroutine＋ランタイム内蔵のI/O多重化」で、ブロッキング風に書いて高並行を得ます。Rust/C#/JSは「スタックレスasync＋イベントループ」で、ゼロコスト寄りの状態機械を選びました。Javaの仮想スレッド（Project Loom）は後発でスタックフルを選び、既存のブロッキングAPIを書き換えずに数十万本へスケールさせる路線です。どれも「スケジュール主体×スタックの持ち方」という同じ2軸の上で、トレードオフの置き所を変えているにすぎません。

まとめ

並行実行単位の違いは、**スケジュール主体（プリエンプティブ/協調的）とスタックの持ち方（スタックフル/スタックレス）**という2軸に集約されます。OSスレッドはカーネルがプリエンプトする重い単位、グリーンスレッド・ファイバーはユーザー空間がM:Nで運ぶ軽量単位で、その多くはスタックフルゆえ深い呼び出し先からでも中断でき関数の色が出ません。スタックレスは状態機械化で関数1個ぶんに畳むため最軽量ですが、awaitが呼び出し連鎖を上へ伝播します。切り替えコストとメモリはOSスレッド＞スタックフル＞スタックレスの順で、各ランタイムはこの2軸の上にトレードオフを置いて設計されています。中断点で「実行の続きと変数」をどこへ退避するか、という一点を起点に見れば、goroutineの軽さからasyncの色問題まで一本の線でつながります。関連する継続の視点は末尾呼び出し最適化と継続(CPS)も併せて押さえると盤石です。