1. PHPターゲットにおけるDCE（Dead Code Elimination）の戦略的真価
PHPというランタイム環境は、シェアードナッシング（Shared-Nothing）アーキテクチャを基本設計としている。リクエストごとにスクリプトが読み込まれ、実行され、破棄される。OPcacheの普及によってコンパイル済みバイトコードのキャッシュが可能になったとはいえ、不要なクラス・メソッドがパース対象に含まれること自体が、OPcacheのメモリ空間を圧迫し、シンボル解決テーブルを肥大化させ、最終的にL1/L2キャッシュミス率の上昇を招く。
HaxeコンパイラにおけるDead Code Elimination (DCE)は、単なる「未実行行のテキスト削除」や「リンカーによる未参照シンボルのカット」ではない。
HaxeのDCEは、型システム（Type System）の統合フェーズ（Typer）が完了した直後、かつクロスプラットフォームの各ターゲットへコード生成する前段のTyped AST（型付き抽象構文木）段階で実行される、完全な依存関係グラフの到達可能性（Reachability）解析である。
[Haxe Source]
│
▼ (Parsing & Type Checking)
[Typed AST (TExpr)]
│
▼
[DCE Engine] ──(Reachability Graph Analysis)──► [Pruning Unused AST Nodes]
│
▼ (Code Generation)
[PHP AST Generator]
│
▼
[Minimal PHP Source Code Files]
本稿では、HaxeコンパイラがどのようにTyped AST上で静的解析を行い、依存グラフを構築し、PHPコードとしての出力を最小化しているのか、その内部メカニズムと低レイヤでの制御手法を解剖する。
—
2. DCEパイプラインと依存グラフの構想（Typed AST上のMark-and-Sweep）
HaxeのDCEアルゴリズムは、ガベージコレクションにおけるMark-and-Sweepアルゴリズムと本質的に同等である。コンパイラ内部（OCaml層）では、以下のフェーズで到達不能コードを特定し、刈り込み（Pruning）を行う。
DCEの3つの動作モード
| モード (`-dce
| :— | :— |
| `no` | DCEを完全に無効化する。すべての型およびメソッドがPHPコードとして生成される。ライブラリ構築時以外では非推奨。 |
| `std` | Haxe標準ライブラリ（`std`）およびサードパーティ製ライブラリの型のみをDCEの対象とする。ユーザー空間のコードはすべて残る。 |
| `full` | 推奨設定。 エントリポイントから到達できないクラス、フィールド、メソッド、インターフェースを全面的に削除する。 |
到達可能性解析の内部メカニズム
`-dce full` 指定時、コンパイラは以下の手順で依存グラフを展開する。
1. Root Set（ルート集合）の決定:
- `Main.main()`（`-main` で指定されたエントリポイント）のノードを最初の「Markドメイン」として登録する。
- `@:keep` アノテーションが付与されたすべてのクラスおよびフィールドをルート集合に無条件追加する。
2. AST走査とエッジの追跡（Mark Phase）:
- ルート集合から開始し、`TExpr`（Typed Expression）の内部を走査する。
- メソッド呼び出し (`TCall`)、変数アクセス (`TField`)、型キャスト (`TCast`)、インスタンス化 (`TNew`) が検知されるたび、対象のシンボル（`TClassDecl`, `TClassField`）へ指向性エッジを伸ばし、Markフラグを立てる。
3. スイープフェーズ（Sweep Phase）:
- Markフラグが立たなかったすべての `TClassField`（メソッド・変数）をASTから除外する。
- クラス内のすべてのフィールドが除去され、かつ自身もMarkされていない場合、その `TClassDecl` 構造自体をコンパイルユニットから破棄する。
PHPターゲットにおいてこの「破棄」が意味するのは、そのクラスに対応する `.php` ファイルの出力そのものがキャンセルされるということだ。
—
3. PHPターゲット特有のDCE構造とエッジケースの解明
PHPターゲットにおけるトランスパイルでは、他言語ターゲット（JavaScriptやC++）と異なり、PHPのランタイムセマンティクスに由来する特殊な制約が存在する。
3.1. リフレクションと動的呼び出し (`Reflect` / `Type`) の暗黒面
Haxeの強力なリフレクションAPI（`Reflect.callMethod` や `Type.createInstance` など）を使用する場合、コンパイラは静的な依存グラフを解体せざるを得ない。
例えば、文字列経由でクラスを動的生成する場合：
var clazz = Type.resolveClass(“core.services.PaymentProcessor”);
var instance = Type.createInstance(clazz, []);
静的解析フェーズにおいて、文字列 `”core.services.PaymentProcessor”` と実際の `PaymentProcessor` クラスの型の間にASTレベルの参照エッジ（`TClassDecl` への参照）は存在しない。この結果、`-dce full` 環境下では `PaymentProcessor` は「未参照」と判断され、生成されるPHPコードから痕跡ごと消去される。
これを防ぎ、コンパイラに依存関係を明示するための機構が以下のアノテーションである。
- `@:keep`: 指定されたクラスまたはフィールドをDCEの走査ルート（Root Set）に加える。
- `@:keepSub`: 指定されたクラス、およびそれを継承するすべてのサブクラスをDCEから保護する。
- `@:rtti`: Run-Time Type Informationを生成し、該当型のメタデータを保持する。
3.2. インターフェースの仮想呼び出しとVTable削減
PHPではインターフェースの実装（`implements`）はランタイムでの型チェックに使われる。HaxeのDCEは、型定義と抽象化の階層を厳密にチェックし、インターフェースのメソッドが実際には一度も呼び出されていない場合、実装クラス側のメソッドを保持しつつ、インターフェース側の宣言のみを消去する。
さらに、あるインターフェースを実装するクラスが単一しか存在せず、かつ直呼び出しに最適化できると判断された場合、PHPコード出力レベルでインライン化が促進され、中間オーバーヘッドが徹底的に削減される。
—
4. 実証：DCE処理前後のコード解析とトランスパイル結果
実際のHaxeコードがどのように解析され、PHPコードへと出力されるか、具体的な検証コードを用いて追跡する。
検証用 Haxeソースコード (`Main.hx`)
package;
interface ILogger {
function log(message:String):Void;
}
class ConsoleLogger implements ILogger {
public function new() {}
public function log(message:String):Void {
// 生のPHP関数呼び出しをインライン展開
php.Global.echo(message + “\n”);
}
}
class FileLogger implements ILogger {
public function new() {}
public function log(message:String):Void {
php.Global.file_put_contents(“app.log”, message + “\n”, php.Const.FILE_APPEND);
}
}
class DeadDeadCode {
public static function unusedMethod():Void {
php.Global.echo(“This should never exist in PHP output.”);
}
}
class Main {
static function main():Void {
// ConsoleLogger のみが静的に参照される
var logger:ILogger = new ConsoleLogger();
logger.log(“Haxe DCE Architecture Active.”);
}
}
—
コンパイルコマンド
DCE FULLモードでPHPターゲットへトランスパイル
haxe -main Main -php bin -dce full
—
出力されたPHPコードの解剖
DCEが完全機能した場合、`DeadDeadCode.php` および `FileLogger.php` は出力ディレクトリ (`bin/lib/`) にファイルすら生成されない。
生成された `ConsoleLogger.php` （要約・抜粋）
生成された `Main.php` （要約・抜粋）
log(“Haxe DCE Architecture Active.”);
}
}
解析結果として：
1. `DeadDeadCode` クラス：完全削除（ファイル非生成）。
2. `FileLogger` クラス：`ILogger` を実装しているにもかかわらず、`main()` からの参照パスが存在しないため完全削除。
3. `ConsoleLogger` クラス：必要なメソッド `log` とコンストラクタのみが残り、出力を最小化。
—
5. アーキテクトのための実戦的メタプログラミングとDCE制御戦略
大規模なトランスパイル型PHPシステムを設計する場合、リフレクションの柔軟性を保ちつつ、DCEによるサイズ・メモリの最適化を極限まで押し進めるためのアーキテクチャが必要となる。
ここで強力な武器となるのがHaxeのマクロシステム（Build Macros）である。コードを静的に走査し、動的呼び出しが必要なクラスにのみピンポイントで `@:keep` を自動付与する構成を作る。
リフレクション自動保護マクロ (`DceProtector.hx`)
以下のマクロは、特定パッケージ配下のクラス群をコンパイル時に自動的に探索し、リフレクションが必要なシンボルにのみ動的に `@:keep` を注入する。これにより、手動での `@:keep` アノテーション散布によるメンテナンス性の低下を防ぐ。
if macro
import haxe.macro.Compiler;
import haxe.macro.Context;
import haxe.macro.Expr;
import haxe.macro.Type;
class DceProtector {
/
- 指定されたパッケージ内のすべてのクラスへ @:keep を自動付与し、
- DCEによる過剰な削りを防ぐビルドマクロ
/
public static function keepPackage(packageName:String):Void {
Context.onGenerate(function(types:Array
for (type in types) {
switch (type) {
case TInst(ref, _):
var cls = ref.get();
if (StringTools.startsWith(cls.pack.join(“.”), packageName)) {
// 該当クラスのメタデータに @:keep を注入
cls.meta.add(“:keep”, [], cls.pos);
}
default:
}
}
});
}
}
end
マクロの適用方法（`build.hxml`）
-cp src
-main Main
-php bin
-dce full
–macro DceProtector.keepPackage(‘core.dynamic.services’)
この構成により、`core.dynamic.services` パッケージ配下のクラス群のみがDCEの対象外（Root Set入り）となり、PHPのリフレクションAPI経由で安全に安全に呼び出せる状態が保証される。それ以外の未使用コード（標準ライブラリやサードパーティライブラリ含む）は、`-dce full` の超高精度な剪定アルゴリズムによって徹底的に切り落とされる。
—
6. 結論
HaxeからPHPへのトランスパイルにおけるDCEは、単なるコード削減ツールではない。それは静的型システムと言語非依存のTyped AST層が実現する、最高峰のコンパイラ最適化エンジンである。
- DCEは Typed AST 上で Mark-and-Sweep 依存グラフ解析 を行い、不要な型・メソッドを根こそぎ排除する。
- 未使用のクラスは、PHPソースコードファイル（`.php`）として出力すらされない。これにより OPcache のメモリ効率とファイルI/Oが劇的に向上 する。
- 動的なリフレクション等で静的グラフが切れる領域は、`@:keep` アノテーションや Haxe Macro によるコンパイル時メタ注入 を駆使して精度高く制御する。
コンパイラ内部の動作原理とPHPランタイムの双方を熟知したアーキテクトにとって、HaxeのDCEは、PHPアプリケーションの実行速度とフットプリントを極限まで削ぎ落とすための最も鋭利な刃となる。