Appleは，SafariのJavaScriptエンジンであるNitroのスピードを35%向上した – JavaScriptをLLVM IRコードに変換して，徹底的な最適化を行う手法によるものだ。
webkit.orgにポストされた記事によると，WebKitのJavaScript内部バイトコードにはこれまで３つの最適化レベルがあり，コード部分の最適化に要する時間とそこから得られるメリットのバランスを取ることで，実行時に使い分けられていた。
- LLInt (Low Level Interpreter) – コンパイラではなくバイトコードインタプリタであり，最適化はほとんど行われない。各関数の呼び出しはLLIntで実行され，100回以上実行されるステートメントが存在するか，あるいは関数自体が6回以上コールされると，その関数は次の最適化レベルであるBaseline JITによって処理される。
- Baseline JIT – シンプルなJITで，LLIntよりも高速なコードを生成するが，高度な最適化は行わない。こちらも同じように，1,000回以上実行されるステートメントないし66回以上コールされる関数を検出すると，次のレベルであるDFG JITにコンパイル処理を転送する。OSR(On-Stack Replacement)を使用することにより，ステートメントを実行した後でコンパイラを切り替えることが可能だ。
- DFG JIT (Data Flow Graph JIT) – 現時点でSafariのパフォーマンスを担うのはこのコンパイラだ。ただしコード最適化に処理時間を要するため，より多くのCPUを必要とするコード部分にのみ使用される。
Nitroのパフォーマンスをさらに向上させるためにAppleは，最適化チェーンにLLVMを導入することを決定した。LLVMコンパイラインフラストラクチャの作成者であり開発リーダであるChris Lattner氏は現在，Appleの開発ツール部門のリーダを務めている。おそらくは今回の開発にも関係しているだろう。FTL JIT(Fourth Tire LLVM)と呼ばれるこの第４層は，内部的にLLVMの低レベル最適化を使用するC++モジュールである。これを実現するため，関数のバイトコードはCPS(Continuation-Passing Style)とSSA(Static Single Assignment)という，２つの内部フェーズを通ってLLVM IRに変換される。これらが元のダイナミックコードをスタティックなコードに変換し，最適化した結果が，LLVMコンパイラによって処理されるのだ。動的言語のプロファイル指示型(profile-directed)コンパイルにLLVMが使用されたのは今回が初めてであり，LLVMの深部にまで変更が必要だった，とFilip Pizlo氏は述べている。
WebKit FTL JITは，動的言語のプロファイル指示型コンパイルにLLVM JITインフラストラクチャが採用された，初めての大規模プロジェクトです。この実現には，WebKitとLLVMの大幅な改造が必要でした。LLVMによるコードのコンパイルには，既存のJITよりもはるかに長い時間が必要です。またWebKitは高度な世代別ガベージコレクタを使用していますが，LLVMは余分なGCアルゴリズムをサポートしていません。プロファイル駆動のコンパイルを行うということは，関数の実行中に最適化コンパイラが起動されるかも知れませんし，ループ処理の最中に関数の実行を最適化されたコードに遷移する可能性もあります。私たちの知る限りFTLは，ループ処理の実行中にLLVMでコンパイルされたコードへのOSRを行う初めてのコンパイラです。もうひとつ，LLVMはこれまで，動的コードの処理に必要な自己修正コードや非最適化(deoptimization)といったトリックをサポートしていませんでした。
Appleはどのような方法で，これを１年間で実現したのだろう？ Pizlo氏によると，SafariはDFG JITの時と比較してRichaｒdsベンチマークで38%，多数のasm.jsベンチマークでも平均35%高速になっているという。OctaneベンチマークによるChromeやFirefoxとの比較結果は，まだ分かっていない。 さらに "FTLの開発は始まったばかりです – コンパイル可能なJavaScriptオペレーションのセットを増やさなければなりませんし，まだ調査していないパフォーマンス向上の余地もあるでしょう。" とPizlo氏は述べている。
FTL JITはWebKitトランクにr167958としてコミットされていて，ナイトリービルドで試すことができる。