こんにちは。日々のPHPアプリケーション開発、本当にお疲れ様です。
他の高水準言語（Java、Node.js、Go、Pythonなど）の経験がある優秀なエンジニアほど、PHPの世界に踏み込んだときに「リクエストが終わればメモリが綺麗に消える手軽さ」の裏側にある、Zendエンジン独自の挙動のギャップに戸惑うことが多いのではないでしょうか。
特に、PHP 8.xで導入されたJIT（Just-In-Time）コンパイラと、古くからPHPを支えてきた参照カウント（Reference Counting）およびガベージコレクション（GC）が、実行時においてどのように協調し、メモリを管理しているのか——。ここを深く理解している人は、シニア層であっても意外と多くありません。
今回は、JITによってネイティブマシン語がバリバリと実行されている最中、Zendエンジンの内部でメモリがどう扱われ、参照カウントがどう操作されているのか。その深淵を一緒に覗いてみましょう。ここがクリアに見えると、巨大なデータ構造を扱うバッチ処理や高負荷なWebAPI設計の視界が、驚くほどクリアになりますよ。
—
1. そもそもPHP 8.xのJITとは「何」を実行しているのか
まず前提として、PHPのJITは「JavaのJVMやC#のCLRのように、プログラム全体を常駐させて動的に最適化し続けるもの」ではありません。
PHPのライフサイクルは基本的に「1リクエスト = 1プロセス（またはスレッド）の起動から終了」という短命な世界を前提としています。PHP 8のJIT（DynASMをベースに実装されています）は、Zend Opcodes（中間コード）を、実行時にx86/x64のネイティブマシン語に翻訳し、CPUの命令キャッシュに直接書き込む仕組みです。
ここで重要なのは、JITが生成したネイティブコード（マシン語）であっても、PHPのオブジェクトや配列の構造体（`zval`）を直接魔法のように消し去るわけではないという点です。JITコードの中身は、突き詰めると「ZendエンジンのC言語で書かれた内部関数（Zend API）や、メモリ操作ルーチンを直接呼び出す高速なバイナリ列」に他なりません。
つまり、JITが動いていようがなかろうが、PHPのメモリ管理の基本原則である「参照カウントによる即時解放」と「循環参照アンカーによるバッチGC」のルールは一切変わらないのです。
—
2. JIT実行中の参照カウント操作：何が高速化の鍵なのか
通常のPHPコード実行時、Zend VMはオペコード（例：`ZEND_ADD`やムーブ系命令）を1つずつインタプリタとして解釈し、その都度変数の型チェックや参照カウントのインクリメント／デクリメント（`Z_ADDREF_P`など）を行っています。この「インタプリタのディスパッチコスト」と「毎回のオーバーヘッド」が、PHPのボトルネックの一つでした。
では、JITが有効になると何が起きるでしょうか。
JITコンパイラは、型が確定している（あるいは推論できる）ループや演算をネイティブのレジスタ演算や直接的なメモリアドレス操作に変換します。例えば、数値をひたすら加算するようなループの場合、インタプリタのオーバーヘッドが消え、CPUのパイプラインを最大限に活かした高速実行が可能になります。
しかし、オブジェクトや配列が絡むと話が変わります。オブジェクトが代入されたり、スコープを抜けたりするとき、Zendエンジンは参照カウントの増減（`refcount`の操作）を正確に行わなければ、メモリリークや二重解放（Segmentation Fault）を引き起こします。
JITネイティブコード内でも、変数の生存期間（ライフタイム）の境界において、参照カウントを操作するためのCレベルのヘルパー関数やインライン展開されたアセンブリがしっかりと実行されています。「JITだから参照カウントをサボっている」のではなく、「参照カウントの整合性を保ったまま、余計なVMのディスパッチングを極限まで削ぎ落としている」というのが、正確な姿です。
—
3. 実践：JITとGCが協調する世界をコードで覗く
百聞は一見に如かず。実際に、巨大なオブジェクトグラフを生成し、参照カウントとGCの協調を意識すべき構造のコードを見てみましょう。
/
class Node {
public ?Node $child = null;
public ?Node $parent = null;
public function __construct(public string $name) {
// オブジェクト生成時にログを仕込む
// echo “Node {$this->name} が生成されました。\n”;
}
public function __destruct() {
// どこからも参照されなくなり、参照カウントが0になった瞬間に呼ばれる
// echo “Node {$this->name} が消滅しました（即時解放）。\n”;
}
}
// JITの恩恵を受けやすい数値計算やオブジェクト生成の密集地帯
function processHeavyGraph(int $iterations): void {
for ($i = 0; $i < $iterations; $i++) {
$parent = new Node("親-{$i}");
$child = new Node("子-{$i}");
// ここで意図的な「循環参照」を作る
$parent->child = $child;
$child->parent = $parent;
// ループを抜けると、$parent と $child のローカル変数スコープが消える。
// 通常の変数であれば、ここで参照カウントが 0 になり即座に __destruct が走る。
// しかし、相互参照（parent <-> child）があるため、
// 参照カウントはそれぞれ「1」残ったままになる！
}
}
// 実行計測
$startMemory = memory_get_usage();
$startTime = microtime(true);
// JITが有効な環境（opcache.jit_buffer_size > 0）下で高速に実行される
processHeavyGraph(100000);
$midMemory = memory_get_usage();
//ここで初めてZend GCが動く、あるいはスクリプト終了時に回収される
gc_collect_cycles();
$endMemory = memory_get_usage();
echo “処理前メモリ: ” . number_format($startMemory) . ” bytes\n”;
echo “構築後（GC前）メモリ: ” . number_format($midMemory) . ” bytes\n”;
echo “GC強制実行後メモリ: ” . number_format($endMemory) . ” bytes\n”;
このコードの裏側で何が起きているか？
1. JITによる高速なオブジェクト生成と参照構築
`processHeavyGraph` 内のループは、JITによって最適化され、非常に高速にネイティブ実行されます。オブジェクトのインスタンス化やプロパティへの代入も、余計なVMオーバーヘッドなしに爆速で処理されます。
2. 参照カウントの壁
ループの各イテレーションが終わるとローカル変数（`$parent`, `$child`）は破棄されますが、お互いを指し合っているため、それぞれの `refcount` は `1` のまま残り、メモリ上に幽霊のように居座ります（これがメモリ肥大化の原因です）。
3. GC（ガベージコレクション）の出番
PHPのGCは、「参照カウントが減ったものの、0にはならず、かつルートバッファ（Roots Buffer）に登録された候補」に対してのみ機能します。`gc_collect_cycles()` が呼ばれると、Zendエンジンは循環参照の疑いがあるメモリ領域をスキャンし、孤立したループを発見して一網打尽に解放します。
JITは「コードを速く実行する」ものですが、メモリのライフサイクルや循環参照の根本的な解決（GCの役割）を肩代わりしてくれるわけではありません。 だからこそ、JIT環境下であっても、メモリリークを防ぐための設計思想（不要になったら `null` を代入して参照を切る、あるいは単方向の依存関係を徹底するなど）が極めて重要になるのです。
—
4. Webアーキテククトとしての知見：本番環境でのチューニング指針
PHP-FPM環境において、1リクエストの寿命は通常数十〜数百ミリ秒です。リクエストが終了すれば、プロセスが保持しているメモリ（Zendプロセスのヒープ）はOSに返却されるか、次のリクエストのためにプールされます。
しかし、長時間のバッチ処理（CLI）や、Swoole / RoadRunnerなどの常駐型PHPランタイムを採用しているモダンなWebシステムでは話が別です。常駐型環境では、JITによって高速化されたコードが何万回も回り、その中で循環参照によるメモリリークが発生すると、数時間でコンテナのメモリ上限（OOM Killer）に到達してしまいます。
ここで、アーキテクトとして押さえておくべき実践的な指針をいくつか提示します。
- JITとGCのトレードオフを理解する
JITはCPUバウンドな処理を劇的に加速させますが、GCの走査頻度を減らすわけではありません。複雑なオブジェクトグラフを多用するドメインモデルをJIT環境下で動かす場合は、意図的に `gc_collect_cycles()` を適切なタイミングで挟むか、そもそも循環参照を作らない設計（値オブジェクトの活用など）を徹底してください。
- OpcodesとJITバッファのサイジング
`php.ini` における `opcache.jit_buffer_size`（例: `128M` など）を適切に設定し、アプリケーション全体のコードがしっかりとJITの恩恵（Machine Code）を受けられるようにプロファイリングを行いましょう。JITが無効（あるいはヒット率が低い）状態では、せっかくのモダンPHPのパフォーマンスをドブに捨てることになります。
—
おわりに
いかがでしたでしょうか？
「JITがネイティブコードを吐いて高速に動く」という華やかな表舞台の裏でも、PHPの根幹であるZendエンジンは、地道に `zval` の参照カウントを管理し、適切なタイミングでGCと連携してメモリの秩序を保っています。
この「低レイヤの裏側がどうなっているか」のイメージさえ頭の中にあれば、パフォーマンスチューニングやメモリリークのデバッグに直面したときも、勘に頼るのではなく、論理的に原因を特定できるようになります。
あなたのPHPアプリケーションが、より堅牢で、かつ極限まで高速に動作することを、心から応援しています。それでは、次のアーキテクチャの旅でお会いしましょう！