HackのAwaitableが隠蔽する「スタックの深淵」：HHVM JITが非同期処理を解体する仕組み
Hackの非同期処理を単なる「便利な糖衣構文」だと思っていないか？
`async`/`await` を乱用し、パフォーマンスのボトルネックを特定できずにいるなら、君はHHVMの心臓部で何が起きているのかを理解していない。
今日は、HHVMのJITコンパイラが `Awaitable` をどう捌き、コンテキストスイッチのコストをどこまで極限に削ぎ落としているのか、その深淵を覗こう。
—
1. スタックの「分断」：非同期処理の裏側
通常の同期関数であれば、スタックフレームは連続したメモリ領域に積まれる。しかし、`async` 関数は呼び出された瞬間に `Awaitable` オブジェクトを返し、即座に制御を呼び出し元へ戻す。
このとき、HHVMは何を行っているのか？
1. スタックのヒープ昇格: 実行中のスタックフレームをメモリ（ヒープ）上に退避させる。
2. 継続（Continuation）の生成: どこまで実行したかという情報を保持した `WaitHandle` を構築する。
3. レジスタ退避: JITが最適化したレジスタ値をメモリへ書き出す。
これが、君たちが何気なく書いている `await` の裏側で行われている「重い」処理だ。非同期処理の多段ネストは、このヒープへの退避・復帰のオーバーヘッドを指数関数的に増大させる。
2. JITが非同期処理で狙う「局所性」の最適化
HHVMのJITは、この「非同期の分断」を最小化するために、Speculative Inlining（投機的インライン化）を駆使する。
もし `await` される対象の `WaitHandle` が既に完了（`Succeeded`）している場合、HHVMはスタックの退避を行わない。「既に結果があるなら、わざわざコンテキストスイッチなどせずに、そのまま実行を継続する」という最適化だ。
これが、なぜ「小規模な非同期処理を大量に並列化する」よりも「I/Oバウンドな大きな固まりを効率的に待つ」ことが重要なのかの答えになる。不必要な `await` の細切れは、JITによるこの最適化パスを阻害する。
—
3. 実務で守るべき「Awaitable」の設計哲学
パフォーマンスを維持しつつ、堅牢性を保つためのプロダクション・パターンを伝授する。
NG: 意味のない細分化
// 悪い例：スタックの分断を無駄に繰り返す
async function get_data(): Awaitable {
$id = await get_id(); // ここで一度スタックが退避される
$user = await get_user($id); // 再度スタックが退避される
return $user;
}
このコードは、I/Oが完了するたびにHHVMがメモリ管理の再計算を行う。小規模な処理なら、`Awaitable` を分解せずに合成すべきだ。
GOOD: 構造化された並列実行
複数のAPIを叩く場合、`GenArrayWaitHandle` を用いるのが鉄則だ。HHVMはこれを単一の非同期境界として処理し、スタックの管理コストを最小化する。
/
- 複数の非同期タスクを最小限のコンテキストスイッチで処理する例
/
async function fetch_user_data_optimized(int $id): Awaitable
// await を並列化し、HHVMのスケジューラに一括で管理させる
// これにより、個別のawaitによる不要なコンテキストスイッチを排除する
list($profile, $settings) = await GenArrayWaitHandle::create(vec[
fetch_profile($id),
fetch_settings($id),
]);
return shape(‘profile’ => $profile, ‘settings’ => $settings);
}
—
4. チーフアーキテクトからの助言
プロダクションコードにおける非同期設計の要諦は以下の3点に集約される。
1. `await` は「境界」と心得よ: `await` を書くたびに、HHVMは「ここから先は非同期かもしれない」というコストを支払う。ループの中での `await` は、パフォーマンス上の地雷になり得る。
2. `Awaitable` を隠蔽するな: `Awaitable
3. プロファイリングを怠るな: `hhvm.jit.trace_counter` や `hhvm.jit.stats` を活用し、`Awaitable` の発行数が不自然に増えていないか監視せよ。
Hackの非同期モデルは、極めて洗練されている。だが、その恩恵を最大化できるかどうかは、君がどれだけ「HHVMがメモリ上でスタックをどう動かしているか」を想像できるかにかかっている。
コードは単なる命令の羅列ではない。それは、CPUとメモリに対する繊細な対話だ。その対話を、論理的かつ冷徹にデザインしてほしい。
健闘を祈る。