博士

ロボ子、今日のITニュースはすごいぞ！Futamura projectionと部分評価だって！

ロボ子

Futamura projectionですか。確か、インタプリタを自動的に変換して、JITコンパイルされたユーザーメソッドを作成する技術でしたよね。

博士

そうそう！言語のセマンティクスをインタプリタとJITで別々に実装しなくて済むのがミソなのじゃ！一度実装すれば、コンパイルされたコードもメモリ安全になるってんだから。

ロボ子

なるほど。インタプリタがメモリ安全なら、変換後のコードも自動的にメモリ安全になる、と。

博士

そういうこと！さらに、Javaにアノテーションで追加された"compilation final"っていう定数性の新しい形式も登場したみたい。

ロボ子

compilation final…ですか。インタプリタ内ではmutableだけど、コンパイル時には定数として扱われる、と。

博士

そう！関数がhotになると、TruffleがGraalコンパイラと連携して、ユーザーコードに対応するインタプリタの部分をコンパイルする時に、compilation finalは定数になるのじゃ。

ロボ子

変数がアクセスされるタイミングでconst-nessが変わるんですね。面白い仕組みです。

博士

ユーザープログラムをロードする時に、配列をオブジェクトで初期化できるのもポイントだぞ。関数がhotになると、`execute()`メソッドのコンパイルが始まり、`this`ポインタがcompilation finalとして扱われる。

ロボ子

`this.statements`も定数として扱われるから、コンパイラはループを展開できるんですね。

博士

その通り！コンパイラは、JavaScriptとかPythonとかC++とか、ユーザーの言語のセマンティクスに合わせたネイティブ関数を生成するのじゃ。

ロボ子

特定の`JavaScriptFunction.execute()`メソッドの呼び出しが転送されて、インタプリタからネイティブコードに移行するんですね。

博士

もしプログラムが動作を変えて、コンパイラの仮定が無効になったら、Truffleはインタプリタにdeoptimizeするぞ。最適化されたCPU状態をインタプリタ状態にマッピングする高度な技術じゃ。

ロボ子

Deoptimizationまで自動的に行うなんて、すごいですね。

博士

じゃろ？つまり、コンパイラは「お前のコード、絶対に変わらないから！」って信じて最適化するけど、もし変わったら「ごめん、やっぱり変わったわ」ってインタプリタに戻る、みたいな感じじゃな。

ロボ子

まるで、浮気しないって言ってた人が、やっぱり浮気しちゃった、みたいな…？

博士

うむ…、まあ、そんな感じかの。でも、Truffleはちゃんと後始末してくれるから安心なのじゃ！