【テクニカル・上級編】PHPのグローバル変数からの脱却：Hackの型システムによる依存関係の注入 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

グローバル状態という「メモリの汚染」を断つ：Hackの型システムによる依存性の純化

PHPのグローバル変数――`$GLOBALS`、`$_SESSION`、あるいは無秩序に散らばった`global`キーワード。これらは単なるコードの可読性問題ではない。HHVMのJITコンパイラから見れば、「予測不可能な副作用の塊」であり、最適化の最大の敵だ。

ランタイムの深淵を知る者ならば理解しているはずだ。グローバル変数はメモリ上のどこでいつ書き換わるか保証がない。これはCPUのパイプライン最適化や、HHVMのプロファイリングガイド付き最適化（PGO）において、レジスタへの変数アロケーションを阻害する「メモリ障壁（Memory Barrier）」として機能する。

本稿では、PHPのレガシーをHackの厳格な型システムで再構築し、実行時のパフォーマンスと安全性を極限まで高めるための「DIによる純化」を説く。

—

1. グローバル変数がHHVMの最適化を殺す理由

HHVMのJITエンジンは、型が確定している領域では極めてアグレッシブにマシンコードを生成する。しかし、グローバルスコープが汚染されていると、コンパイラは「いつどこで変数が更新されるか分からない」という前提に立たざるを得ない。

エイリアス解析の失敗: グローバル変数への書き込みは、あらゆる関数呼び出しの裏側で発生する可能性があるため、コンパイラはメモリロードを省略できず、何度もキャッシュミスを引き起こす。
脱糖化の重荷: `global`キーワードは、実際にはシンボルテーブルへのハッシュマップ検索を伴う。これはホットパスにおいて無視できないレイテンシを生む。

我々はこれを「依存性の注入（DI）」によって、スタック領域あるいはヒープ上の確定したポインタへと変換しなければならない。

—

2. Hackの型システムでDIを「定数化」する

PHPではDIと言えば配列や動的なクラスバインディングが一般的だが、Hackでは型エイリアスとインターフェースを用いたコンパイル時解決を目指すべきだ。

移行の戦略：インターフェースによる境界の強制

まず、グローバル変数に依存していたロジックを、`<<__ConsistentConstruct>>`（※継承時の型安全性の担保）を付与したインターフェースへと切り出す。

namespace App\Infrastructure;

// グローバルなDB接続を隠蔽するためのインターフェース
interface IDatabaseConnection {
public function query(string $sql): vec>;
}

// 実装はfinalで閉じ、JITによるDevirtualization（仮想呼び出しの直接呼び出し化）を促す
final class MySQLConnection implements IDatabaseConnection {
public function __construct(private string $dsn) {}

public function query(string $sql): vec> {
// 実際の低レイヤ接続処理
return vec[];
}
}

ここで重要なのは、`final`を付与することで、HHVMのJITエンジンに「このクラスがこれ以上拡張されない」という確信を与え、メソッド呼び出しのオーバーヘッドを劇的に削減させることだ。

—

3. HSLによる型安全なコンテナの実装

DIコンテナを作る際、PHP的な`mixed`を返すような設計は悪手である。HHVMの型チェッカーを最大限に活用し、依存関係を「型」として静的に固定する。

use type App\Infrastructure\IDatabaseConnection;

final class Container {
// コンテナ内部はメモリ効率の高いdictを使用
private dict $services = dict[];

public function register(classname $class, T $instance): void {
$this->services[$class] = $instance;
}

// 型パラメータTを用いることで、実行時のキャストを排除する
public function get(classname $class): T {
$instance = $this->services[$class] ?? null;
if ($instance is T) {
return $instance;
}
throw new Exception(“Dependency not found: ” . $class);
}
}

この実装において、`classname`を使用することで、IDEおよびHackコンパイラは「どのクラスがどの型を返すか」を厳密に追跡できる。これは単なる規約ではなく、メモリ安全性（Memory Safety）の確保だ。

—

4. 限界への挑戦：低レイヤからの視点

移行の際、以下の3点に注意を払うことが、シニアエンジニアとしての最低限の責務である。

1. Boxingの回避:
Hackの`vec`や`dict`は、プリミティブ型を格納する際、可能な限りアンボクシングされた状態で保持される。DIコンテナでインスタンスを管理する際、過剰なラッパーを作るとヒープアロケーションが増大する。必要な層以外は透過的に注入せよ。

2. `<<__Memoize>>`の戦略的配置:
DIされたインスタンスが不変（Immutable）であるならば、生成メソッドに`<<__Memoize>>`を付与せよ。これにより、HHVMは初回生成時のポインタをキャッシュし、以降の依存解決をポインタのロード一発で完結させる。

3. 型チェッカーの限界を突破する:
複雑な依存関係で`Typechecker error`が出た場合、安易に`unsafe_cast`を使うな。`shape`型を用いたインターフェースの合成や、`newtype`によるカプセル化で、コンパイラに「正しさ」を証明させるのだ。

結び

グローバル変数からの脱却とは、単なるコードの整理整頓ではない。それは、「予測不可能な副作用」をコンパイラの管理下に置き、HHVMが最大限の力を発揮できる「クリーンな実行空間」を創造するプロセスである。

君たちが書く一行のコードが、メモリを効率的に使い、JITが喜んでマシンコードに変換するような構造になっているか？それを常に自問自答せよ。Hackの型システムは、そのための最強の武器だ。使いこなせ。