Perfを重視する必要がでてきます。ネイティブコードにコンパイルされていなくてはいけません。それがデスクトップ型のコンピューターであれば、メモリも潤沢なので、大量のメモリ消費を犠牲にネイティブコードをさらに幾度に渡り最適化させます。これはあくまでデスクトップ型コンピューターの場合。呼び出すコードであっても、モバイルの場合は同じアプローチにはなりません。Androidデバイスはモバイルなので、デスクトップと同じようにメモリを扱うことはできません。ネイティブのコードへコンパイルはされますが、メモリの消費量は抑えられるよう最適化は制限されます。別のパターンについても考えてみましょう。これはNode上で実行されているコードです。Perfを改善しようとしますね。...IoTデバイス上で動作するとなると、同じ状況とは言えません。サーバー用マシンとは異なり、メモリ消費は抑えなくてはいけません。Perfを上げるようにはしますが、それはメモリ消費が少なくて済むようなアプローチで進めます。同じ一行のfunction呼び出しであっても、その最適化方法は無数にあり、コンテキストやデバイスの状況に強く依存するのです。Perfに最適化していくのか、メモリを富豪的に扱うのか、それとも小さくなるよう努力するのか、解決しなくてはいけません。WebAssembly等)に対応できるよう、2〜3年かけて実行パイプラインを作り変えました。過去の変遷を見てみると。2008年のリリース時点の段階では、シンプルなコードジェネレーターがあって、そこからやや最適化を行ったマシンコードが生成されるだけでした。あらゆるJavaScriptのコードは、この仕組を使って実行されます。最適化には計算が必要なため、コードを実行できる状態にするまでに多くの時間を要します。Time短縮するために最適化の処理をスキップすることが求められます。2010年にコンパイラ「Crankshaft」が追加されます。計算コストの高い最適化処理を分離し、Crankshaftにその責務が委譲されました。Timeが最適化されます。Perfにとって最適なマシンコードが生成されます。実行時に、CrankShaftが吐き出したコードを、Full-codegenが吐き出したコードへ置き換えることで最適化を図ります。Crankshaftには限界が来ます。WebAssembly等)にも十分に対応できませんでした。当時のフロントエンドエンジニアなら、V8のECMAScript標準への対応の遅れに苛立ちを感じたはずです。V8開発チームは、それを改善しようと新たなコンパイラ「TurboFan」を追加します。「Ignition」と呼ばれる仕組みを追加しました。Ignitionには、ソースコードをいきなりマシンコードにするのではなく、バイトコード(マシンコードほどハードウェアに依存しない「中間コード」と呼ばれるもの)を生成するコンパイラーと、それを実行するインタプリターが内包されています。TurboFanはバイトコードを扱う形へと作り変えられました。現在、最新のVersionである5.9では、この2つの仕組みは既に使われていません。内部にコードこそ存在していますが、バイトコードの生成と解釈するインタープリターIgnitionと、PeakPerfを改善するための処理をするコンパイラーTurboFanだけで動作しているという状況です。これからまもなくリリースされる6.0では、コードとして完全にV8から削除されます。Interpreter」とは?中間コードを生成して実行するインタプリター。Startupも最適という特徴があります。モバイルなどのメモリの小さな環境で動かすのに最適。Timeに最適化すべきコードの実行に向いている。TurboFanと組み合わせることで、実行速度を最適化できる。「TurboFan」とは?主として、最適化を行うことを目的としたコンパイラー。使われ方としては、拡張的な感じ。あらゆる新しいJavaScript機能に対応していき、その場合も活用される。WebAssemblyのバックエンドでもある。最近はtry/catch/finallyとか、ES2015+の最適化が可能になった。まとめV8について、メモリ管理向けガーベジコレクター「Orinoco」など、さまざまな技術要素が進化し、語り尽くせないほどのトピックがあるのですが、それはまた別の機会にお話しましょう。TurboFanへの完全移行、実態としてすでにほとんど終わった状況といっても過言ではありませんが、8年前とは全く異なる、Web・JavaScriptの変化に追従する大きな変化です。