【実務・中級編】HHVMのJITにおける「ループ不変量コード移動（LICM）」の適用範囲 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hack言語を深く愛し、その性能の限界に挑み続ける諸君、そしてHHVMの心臓部で脈打つJITコンパイルの真髄を解き明かしたいと願う勇敢なエンジニアたちよ。私はHackコアコミッターとして、これまで多くのプロダクション環境におけるパフォーマンスのボトルネックと、それを打ち破るための設計原則を君たちに伝授してきた。

今日は、HHVMのJITコンパイルが持つ最も強力かつ、しばしば誤解されがちな最適化の一つである「ループ不変量コード移動（Loop-Invariant Code Motion, LICM）」について、その深淵を覗き込もう。単なる機能紹介ではない。なぜ、どのように、そして君たちのコードがこの最適化の恩恵を最大限に受けるためには、どのような意識と設計が必要なのか。その本質を、チーフアーキテクトとしての視点から徹底的に解説する。

この知見は、君たちのプロダクションコードの品質を一段引き上げ、バグの起きにくい堅牢なシステムを構築するための強力な武器となるだろう。

—

HHVMのJITコンパイル構造とLICMの立ち位置

まず、HHVMのJIT（Just-In-Time）コンパイルがどのような哲学に基づいているかを理解する必要がある。HHVMは、HackやPHPのコードを直接実行するのではなく、内部的に中間表現（Intermediate Representation, IR）に変換し、それを動的にマシンコードにコンパイルして実行する。このプロセスの中で、様々な最適化パスが適用される。LICMもその一つであり、ループの実行コストを劇的に削減するために不可欠な最適化だ。

JITコンパイラは、コードの実行中にプロファイリング情報を収集し、ホットな（頻繁に実行される）パスを特定する。そして、これらのホットパスに対して、より積極的な最適化を施す。LICMは、特にループ処理において、同じ計算が繰り返し行われる無駄を省くことで、CPUサイクルを節約し、実行速度を向上させる。

ここで重要なのは、JITコンパイラが「何をループ不変量と判断できるか」だ。この判断の精度こそが、LICMの効果を左右する。そして、その精度を高める上で、Hackの静的型システムが極めて重要な役割を果たす。型情報が豊富であればあるほど、JITはコードの振る舞いを正確に予測でき、より安全かつアグレッシブな最適化を適用できるのだ。

ループ不変量コード移動 (LICM) の本質とは

LICMとは、ループの反復回数に関わらず、その結果が変わらない計算（ループ不変量）を、ループが始まる前に一度だけ実行し、その結果をループ内で再利用する最適化である。これにより、ループがN回実行される場合、N回の計算が1回に削減される。

例として、次のようなコードを考えてみよう。

// Bad Example: LICMの恩恵を受けにくいコード
function processItems(vec $items): vec {
$results = vec[];
foreach ($items as $item) {
// strlen()は引数が同じであれば常に同じ結果を返す純粋な関数
// しかし、ループ内で毎回呼び出されている
$length = strlen($item);
// … $length を使った何らかの処理 …
$results[] = $length 2;
}
return $results;
}

この `strlen($item)` は、もし `$item` がループ内で変更されないのであれば、ループの各反復で同じ計算を繰り返すことになる。JITはこれを検出し、以下のような論理的な変換を行う可能性がある。

// HHVM JITのLICMが適用された後のイメージ (概念的なコード)
function processItemsOptimized(vec $items): vec {
$results = vec[];
foreach ($items as $item) {
// JITが strlen($item) をループ外に移動させることはできない
// なぜなら $item はループ変数であり、各反復で異なる値を取る可能性があるから
// この例では、strlen($item) はループ不変量ではない
// (ここで説明しているのは一般的なLICMの概念であり、この例がLICMの対象ではないことを示す)

// 正しいLICMの例は後述するが、まずは “不変量” の定義を明確にする
// $item はループの各イテレーションで変わるので、strlen($item) はループ不変ではない
$length = strlen($item); // これは依然としてループ内で計算される
$results[] = $length 2;
}
return $results;
}

訂正と本質: 上記の `strlen($item)` は、`$item` がループ変数であるため、LICMの直接的な対象とはならない。LICMの真骨頂は、ループのどの反復においても値が変わらない計算を外に出すことにある。私の説明が不十分だった。チーフアーキテクトとして、この誤解を正さなければならない。

真のループ不変量とは、例えば次のようなものだ。

// 真のループ不変量の例
function processWithConstant(vec $items, string $prefix): vec {
$results = vec[];
foreach ($items as $item) {
// $prefix . “__” はループの各反復で結果が変わらない
$prefixedItem = $prefix . “__” . $item; // JITは $prefix . “__” をループ外に出す可能性がある
$results[] = $prefixedItem;
}
return $results;
}

この例では、`$prefix . “__”` の部分がループ不変量となり得る。もし `$prefix` がループ内で変更されないことが保証されていれば、JITはこの文字列連結の計算をループ開始前に一度だけ行い、その結果を変数にキャッシュし、ループ内でその変数を再利用する、という最適化を適用できる。

JITが「ループ不変量」と判断するもの

JITがループ不変量と判断できるのは、主に以下の条件を満たす計算だ。

1. 純粋な関数呼び出し: 引数が同じであれば、常に同じ結果を返し、外部の状態を変更しない（副作用がない）関数。例: `strlen()`, `count()`, `sqrt()` など。
2. 定数やリテラル: `$x = 100;` のような直接的な値。
3. ループの外側で計算された変数: ループ内で値が変更されないことが保証される変数。
4. オブジェクトのプロパティアクセス: ループ内でオブジェクト自体やそのプロパティが変更されないことが保証される場合。
5. 配列の要素アクセス: ループ内で配列自体やその要素が変更されないことが保証される場合。

ここでHackの静的型システムが力を発揮する。JITは、Hackの型ヒントやアノテーションから、関数が純粋であるか、オブジェクトや配列がイミュータブルであるか、変数の値がループ内で変化しないか、といった情報をより確実に推論できる。これにより、JITはより大胆かつ安全にLICMを適用できるのだ。

LICMの適用範囲と限界：本質を見極めろ

JITは魔法ではない。JITが最適化できる範囲と、開発者が手動で最適化すべき範囲を明確に理解することが、高性能なアプリケーションを構築する上での鍵となる。

LICMが適用されるケースの具体例

1. 純粋な関数呼び出しと定数的な計算

最も基本的なケースだ。

// JITがLICMを適用しやすい例
function calculateScores(vec $values, float $multiplier): vec {
$results = vec[];
// $multiplier 10.0 はループ不変量
// JITはこれをループ外で一度だけ計算し、$effectiveMultiplierのようなテンポラリ変数に格納する
foreach ($values as $value) {
$results[] = (float)$value ($multiplier 10.0);
}
return $results;
}

この例では `($multiplier 10.0)` の計算はループの各反復で同じ結果を返すため、JITはこの計算をループ外に移動させる。

2. オブジェクトプロパティへのアクセス

オブジェクトのプロパティがループ内で変更されない場合、そのアクセスもループ不変量となり得る。

class Config {
public function __construct(public int $batchSize) {}
}

function processBatches(vec $data, Config $config): void {
// $config->batchSize はループ内で変更されないことが保証されている場合
// JITは $config->batchSize のアクセスをループ外に移動させる可能性がある
for ($i = 0; $i < count($data); $i += $config->batchSize) { // ここで $config->batchSize を使っている
// … 処理 …
}
}

JITは、`Config::$batchSize` が `final` プロパティであったり、`Config` オブジェクトが `readonly` であったり、あるいは型チェッカーがそのプロパティがループ内で変更されないことを証明できれば、このプロパティアクセスをループ外に移動できる。

3. 関数呼び出しの純粋性の保証

Hackでは、`<<__Pure>>` アトリビュートを使用して関数の純粋性を明示的に宣言できる。これにより、JITはより確実にLICMを適用できる。

<<__Pure>>
function calculateTaxRate(string $region): float {
// 実際にはDBアクセスや複雑なロジックがあるかもしれないが、
// 引数 ($region) が同じなら常に同じ結果を返すことを保証
if ($region === “JP”) return 0.10;
if ($region === “US”) return 0.08;
return 0.05;
}

function processOrders(vec $orders, string $customerRegion): vec {
$finalPrices = vec[];
// calculateTaxRate($customerRegion) は <<__Pure>> なので、
// JITはこれをループ外で一度だけ計算できる
foreach ($orders as $order) {
$taxRate = calculateTaxRate($customerRegion); // この呼び出しがLICMの対象となり得る
$finalPrices[] = $order->getBasePrice() (1 + $taxRate);
}
return $finalPrices;
}

`<<__Pure>>` は、開発者がJITに対して「この関数は副作用がなく、引数に基づいて決定論的に結果を返す」という強力なヒントを与える。これはパフォーマンス最適化だけでなく、コードの保守性やテスト容易性にも大きく寄与する堅牢な設計パターンだ。

LICMが適用されない、あるいは注意が必要なケース

JITが「安全に」ループ不変量と判断できない場合、LICMは適用されない。

1. 副作用のある関数呼び出し

I/O操作、グローバル状態の変更、`rand()` のような非決定的な関数などは、副作用があるためLICMの対象外だ。

// LICMが適用されない例: 副作用のある関数
function logMessage(string $message): void {
// 実際にはファイルに書き込んだり、ネットワークに送信したりする
// これは副作用のある関数なので、ループ外に移動することはできない
echo “LOG: {$message}\n”;
}

function processLogs(vec $messages): void {
foreach ($messages as $msg) {
logMessage(“Processing: {$msg}”); // 毎回呼び出される
}
}

この `logMessage()` は、呼び出すたびに異なる効果（ログの出力）をもたらすため、JITはこれをループ外に移動できない。移動してしまうと、ログの順序が狂ったり、一部のログが出力されなくなったりする可能性がある。

2. ループ内で変更される可能性のある値

オブジェクトのプロパティや配列の要素が、ループ内で変更される可能性がある場合、JITはそれを不変量と見なせない。

class Counter {
public int $count = 0;
public function increment(): void { $this->count++; }
}

function processWithCounter(vec $items, Counter $counter): void {
foreach ($items as $item) {
$counter->increment(); // ループ内で $counter->count が変更される
// $counter->count はループ不変量ではないので、JITはこれをループ外に出せない
echo “Item {$item}, Counter: {$counter->count}\n”;
}
}

`$counter->count` はループの各反復で値が変わるため、当然ながらLICMの対象にはならない。

3. 時間依存の関数

`microtime(true)` や `time()` など、呼び出すたびに異なる結果を返す関数もLICMの対象外だ。

// LICMが適用されない例: 時間依存の関数
function measureLoop(int $iterations): void {
$startTime = microtime(true);
for ($i = 0; $i < $iterations; $i++) { // microtime(true) は呼び出すたびに異なる値を返す // JITはこれをループ外に移動できない echo "Current time: " . microtime(true) . "\n"; } $endTime = microtime(true); echo "Total time: " . ($endTime - $startTime) . "\n"; } このような関数をループ外に出してしまうと、常に同じ時間が表示され、プログラムの意図が完全に損なわれる。

実践的コード例とパフォーマンスへの洞察

では、実際にJITのLICMを意識したコードと、そうでないコードがパフォーマンスにどのような影響を与えるか、具体的な例を通じて見ていこう。

Bad Example: JITの最適化を阻害するパターン

以下は、`strlen()` がループ変数に適用されているため、LICMの対象にならないという典型的な誤解を招くコードではない。そうではなく、オブジェクトプロパティへのアクセスが、JITにとって不確実性をもたらす例を示す。

$endpoints,
AppConfig $config,
): dict {
$results = dict[];
foreach ($endpoints as $endpoint) {
// BAD: $config->timeoutMs はループ内で変更されないように見えるが、
// JITは $config オブジェクト自体がループ内で変更される可能性を排除できないため、
// $config->timeoutMs のアクセスをループ外に移動することを躊躇するかもしれない。
// その結果、毎回プロパティのロードが発生し、オーバーヘッドとなる。
$timeout = $config->timeoutMs;
$results[$endpoint] = callExternalService($endpoint, $timeout);
}
return $results;
}

// 実行例
$config = new AppConfig(“v1”);
$endpoints_to_call = vec[
“api/users”,
“api/products”,
“api/orders”,
“api/inventory”,
“api/shipping”,
];

echo “— Bad Example Execution —\n”;
$start_time = microtime(true);
processRequests($endpoints_to_call, $config);
$end_time = microtime(true);
printf(“Execution time: %.4f ms\n”, ($end_time – $start_time) 1000);

なぜこれは「Bad」なのか？

`$config->timeoutMs` はループ内で値が変更されていません。しかし、Hackの型システムは、`AppConfig` オブジェクトがミュータブルであるため、理論的にはループ内のどこかで `AppConfig` オブジェクトの別のメソッドが呼び出され、`$timeoutMs` が変更される可能性を排除できません。

JITコンパイラは、このような不確実性がある場合、安全サイドに倒れてLICMを適用しません。つまり、ループの各反復で `$config` オブジェクトから `$timeoutMs` プロパティをロードするという、わずかではあるが繰り返しのオーバーヘッドが発生するのです。これは、特にループ回数が多い場合や、プロパティアクセスが複雑なオブジェクトチェーンを伴う場合に顕在化します。

Good Example: JITの最適化を最大限に引き出すパターン

JITが安全にLICMを適用できるようにするには、不変量を明示的にループ外に「手動で」引き出すか、Hackの型システムで不変性を保証する。

$endpoints,
ReadonlyAppConfig $config,
): dict {
$results = dict[];
// GOOD: $config->timeoutMs をループ外で一度だけ変数にキャッシュする。
// JITは ReadonlyAppConfig のプロパティが不変であることを型システムから推論でき、
// この $config->timeoutMs のアクセス自体をループ外に移動する最適化を行う可能性が高まる。
// 例えJITがそれをしなかったとしても、開発者自身が一度だけロードしているため、パフォーマンスは保証される。
$effectiveTimeout = $config->timeoutMs; // 手動でループ不変量を外に出す

foreach ($endpoints as $endpoint) {
$results[$endpoint] = callExternalService($endpoint, $effectiveTimeout);
}
return $results;
}

// 実行例
$readonlyConfig = new ReadonlyAppConfig(“v1”);
$endpoints_to_call = vec[
“api/users”,
“api/products”,
“api/orders”,
“api/inventory”,
“api/shipping”,
];

echo “\n— Good Example Execution —\n”;
$start_time = microtime(true);
processRequestsOptimized($endpoints_to_call, $readonlyConfig);
$end_time = microtime(true);
printf(“Execution time: %.4f ms\n”, ($end_time – $start_time) 1000);

なぜこれは「Good」なのか？

1. `readonly` 修飾子の活用: `ReadonlyAppConfig` クラスのプロパティに `readonly` を付けることで、Hackの型チェッカーはコンストラクタ以外でこれらのプロパティが変更されないことを保証します。この情報はJITコンパイラに伝達され、`$config->timeoutMs` へのアクセスがループ不変であると判断する強力な根拠となります。JITは、このプロパティロードをループの外に安全に移動させることができます。
2. 手動でのキャッシュ: `$effectiveTimeout = $config->timeoutMs;` のように、ループの前に一度だけプロパティの値をローカル変数に格納しています。これにより、JITが自動的にLICMを適用しなくても、開発者自身がプロパティのロードを1回に削減しているため、パフォーマンスのオーバーヘッドを確実に排除できます。これは「JITが最適化してくれるだろう」という期待に依存せず、堅牢なパフォーマンスを保証する設計パターンです。

実際にこれらのコードを実行しても、`usleep()` の時間が支配的になるため、肉眼で明確な時間差を見るのは難しいかもしれません。しかし、HHVMの内部プロファイリングツール（`perf` や `xhprof` など）でJITのIR（中間表現）を見れば、この最適化の違いが明らかになるでしょう。JITは `ReadonlyAppConfig` のケースではプロパティロード命令をループの前に移動させるか、あるいはループ内でローカル変数を参照するようにIRを書き換えます。

堅牢な設計パターンとパフォーマンス上の注意点

このLICMの原理を理解することは、単にJITの機能を知るだけでなく、より堅牢でパフォーマンスの高いHackコードを書くための設計思想を身につけることにつながる。

設計パターン

1. 純粋な関数を意識的に設計する (Pure Function):

関数が引数以外の外部状態に依存せず、副作用も持たない場合、それは「純粋な関数」である。
Hackの `<<__Pure>>` アトリビュートを積極的に利用し、その純粋性をJITに明示的に伝える。これにより、JITは安心してLICMや他の最適化を適用できるようになる。
純粋な関数は、テスト容易性や並行処理の安全性も向上させる。

2. イミュータブルなデータ構造の活用:

`readonly` クラスやプロパティ、あるいは`ImmVector`, `ImmMap` などのイミュータブルコレクションを使用する。
オブジェクトやデータの状態が一度構築されたら変更されないことを保証することで、JITはプロパティアクセスや要素アクセスがループ不変であると判断しやすくなる。
これにより、複雑なデータ構造のアクセスであってもLICMの恩恵を受けられる可能性が高まる。

3. 依存性の注入 (DI) とコンテキストの分離:

ループ内で外部リソース（DBコネクション、設定オブジェクトなど）にアクセスする場合、それらをコンストラクタやメソッド引数を通じて注入する。
注入されたオブジェクトがループ内で変更されないことを保証できれば、そのプロパティアクセスをループ不変量として扱うことができる。
特に設定オブジェクトなどは、`readonly` クラスとして設計し、ループの前に必要な値をローカル変数にキャッシュする習慣をつけよう。

パフォーマンス上の注意点

1. JITは万能ではない。手動最適化の余地は常にある:

JITは非常に賢いが、常にコードの意図を完全に理解できるわけではない。特に、副作用が隠れている可能性のあるコードや、型情報が不足している動的なコードでは、JITは安全側に倒れて最適化を控える。
「JITがやってくれるだろう」と漫然と待つのではなく、ループ不変量であることが明らかな計算やプロパティアクセスは、積極的にループの外に引き出す習慣をつけよう。これはJITの有無にかかわらず、優れたプログラミング習慣だ。

2. プロファイリングの重要性:

どのような最適化も、必ずプロファイリングに基づいて効果を確認すべきだ。「早く動くはずだ」という思い込みは危険だ。
Hack/HHVMには `xhprof` や `perf` (Linuxのツールと連携) など、強力なプロファイリングツールがある。これらのツールを使って、実際のボトルネックがどこにあるのかを特定し、LICMが効果を発揮しているか、あるいはさらなる手動最適化が必要かを判断する。

3. メモリ使用量とのトレードオフ:

LICMは計算時間を削減するが、ループ不変量を保持するための追加の変数（キャッシュ）が必要になる場合がある。
通常、このメモリオーバーヘッドは微々たるものであり、CPU時間の節約効果の方が大きいが、極端に大きなデータ構造をループ外にキャッシュする場合は、メモリ使用量も考慮に入れる必要がある。

まとめ：Hackを掌握する極限の知見

HHVMのJITコンパイラにおけるLICMは、Hackコードのパフォーマンスを向上させるための強力な基盤となる。しかし、その恩恵を最大限に引き出すためには、JITの動作原理、特に「ループ不変量」とは何か、そして「副作用」の厳密な定義を理解することが不可欠だ。

そして何よりも、Hackの静的型システムがJITの最適化、とりわけLICMの安全な適用にどれほど貢献しているかを忘れてはならない。`readonly` プロパティや `<<__Pure>>` 関数といった言語機能は、単にコードの堅牢性を高めるだけでなく、HHVMの心臓部にあるJITコンパイラに、より深い洞察と最適化の機会を提供しているのだ。

君たちエンジニアは、この知見を胸に、単に「動く」コードではなく、「速く、堅牢で、保守性の高い」プロダクションコードを設計し、実装する責任がある。JITは君たちの強力な味方だが、その力を最大限に引き出すのは、紛れもなく君たち自身の深い理解と、それを反映した賢明なコーディング習慣だ。

今日の解説が、君たちのHack開発における新たな視点と、更なる高みへの一歩となることを願っている。Hackの可能性は無限大だ。共にその限界を押し広げよう。