JSの仕組み：V8内部とコードの最適化について

これは、V8エンジンの例を使用したJavaScriptの機能に特化したシリーズの2番目の資料です。 最初は、V8ランタイムメカニズムとコールスタックについて話しました。 今日は、JSのソースコードが実行可能プログラムに変わるV8の機能を詳しく調べ、コードを最適化するためのヒントを共有します。

JSエンジンについて

JavaScriptエンジンは、プログラム、つまりJavaScriptで記述されたコードを実行するインタープリターです。 エンジンは、さまざまなアプローチを使用して実装できます。従来のインタープリターの形式で、動的コンパイラー（またはJITコンパイラー）の形式で、プログラムを実行する前に、JSのソースコードを特定の形式のバイトコードに変換します。



一般的なJavaScriptエンジンの実装のリストを以下に示します。

• V8はC ++で記述されたオープンソースエンジンで、Googleが開発中です。
  
  
• Rhino-このオープンソースエンジンはMozilla Foundationをサポートし、完全にJavaで書かれています。
  
  
• SpiderMonkeyは、Netscape Navigatorで過去に使用され、今日Firefoxで使用された最初のJSエンジンです。
  
  
• JavaScriptCoreは、Nitroとして知られ、AppleがSafariブラウザ用に開発した別のオープンソースエンジンです。
  
  
• KJSは、KDEプロジェクトの一部であるKonquerorブラウザ用にHarry Portenが開発したKDE JSエンジンです。
  
  
• Chakra（JScript9）-Internet Explorer用のエンジン。
  
  
• Chakra（JavaScript）は、Microsoft Edgeのエンジンです。
  
  
• Nashornは、Oracleが関与するOpenJDKの一部であるオープンソースエンジンです。
  
  
• JerryScriptは、モノのインターネット用の軽量エンジンです。
  
  

この記事では、V8の機能に焦点を当てます。

なぜV8エンジンが作成されたのですか？

オープンソースのV8エンジンはGoogleによって作成され、C ++で記述されています。 このエンジンは、Google Chromeブラウザーで使用されます。 V8が他のエンジンと異なる点に加えて、一般的なサーバー環境Node.jsで使用されています。



V8ロゴ



V8を設計する際、開発者はブラウザーでJavaScriptのパフォーマンスを向上させることに着手しました。 プログラムの高速実行を実現するために、V8はインタープリターを使用せずにJSコードをより効率的なマシンコードに変換します。 エンジンは、プログラムの実行中にJavaScriptコードをマシン命令にコンパイルし、SpiderMonkeyやRhino（Mozilla）などの多くの最新のJavaScriptエンジンのような動的コンパイルメカニズムを実装します。 主な違いは、JSプログラムの実行時にV8がバイトコードまたは中間コードを使用しないことです。

V8で使用された2つのコンパイラーについて

内部デバイスV8は、最近登場したバージョン5.9のリリースで変更されました。 その前に、彼は2つのコンパイラーを使用しました。

• full-codegenは、比較的低速のマシンコードを生成するシンプルで非常に高速なコンパイラです。
  
  
• クランクシャフトは、最適化されたコードを生成する、より複雑な最適化JITコンパイラです。
  
  

エンジン内でいくつかのスレッドが使用されます。

• それから期待できるものを扱うメインスレッド：ソースJSコードを読み取り、それをコンパイルして実行します。
  
  
• メインスレッドの実行中にコードを最適化するコンパイルスレッド。
  
  
• プロファイラーのフロー。プログラムが最も多くの時間を費やすメソッドについてシステムに通知します。その結果、Crankshaftはこれらのメソッドを最適化できます。
  
  
• ガベージコレクションメカニズムをサポートするいくつかのスレッド。
  
  

JSコードの最初の実行時に、V8は完全なcodegenコンパイラーを使用します。このコンパイラーは、追加の変換なしで、解析するJavaScriptコードをマシンコードに直接変換します。 これにより、マシンコードの実行をすばやく開始できます。 V8はプログラムの中間バイトコード表現を使用しないため、インタープリターは不要です。



コードがしばらく実行された後、プロファイラーストリームは十分なデータを収集するため、システムは最適化する必要のあるメソッドを把握できます。



次に、別のスレッドで、最適化はクランクシャフトから始まります。 静的な単一割り当て（SSA）モデルを使用して、抽象JavaScript構文ツリーを高レベルの表現に変換します。 このビューは、水素と呼ばれます。 クランクシャフトは、水素制御フローグラフの最適化を試みます。 ほとんどの最適化はこのレベルで実行されます。

埋め込みコード

プログラムの最初の最適化は、可能な限り多くのコードを事前に呼び出し場所に統合することです。 埋め込みコードとは、関数呼び出しコマンド（関数が呼び出される行）を本文に置き換えるプロセスです。 この簡単な手順により、次の最適化をより生産的にすることができます。









関数呼び出しはその本体に置き換えられます

非表示のクラス

JavaScriptはプロトタイプベースの言語です。クラスはありません。 ここのオブジェクトは、クローン作成プロセスを使用して作成されます。 さらに、JSは動的プログラミング言語です。つまり、オブジェクトのインスタンスを作成した後、新しいプロパティを追加したり、既存のプロパティを削除したりできます。



ほとんどのJSインタープリターは、（ ハッシュ関数の使用に基づく）辞書のような構造を使用して、オブジェクトのプロパティ値の場所に関する情報をメモリに保存します。 このような構造を使用すると、JavaやC＃などの非動的言語よりもJavaScriptでプロパティ値を取得するのが難しくなります。 たとえば、Javaでは、オブジェクトのすべてのプロパティは、プログラムのコンパイル後に変更されないオブジェクト回路によって決定され、動的に追加または削除することはできません（C＃には動的型があることに注意する必要がありますが、ここでは無視できます）。 その結果、プロパティ値（またはこれらのプロパティへのポインタ）は、メモリ内の連続したバッファとして、固定オフセットで保存できます。 オフセットステップはプロパティのタイプに基づいて簡単に決定できますが、JavaScriptではプログラムの実行中にプロパティのタイプが変わる可能性があるため、これは不可能です。



辞書を使用してメモリ内のオブジェクトプロパティのアドレスを把握するのは非常に非効率的であるため、V8は代わりに別のメソッドを使用します：隠しクラス 非表示クラスは、実行時に作成されることを除いて、Javaなどの典型的なオブジェクト指向プログラミング言語の通常のクラスに似ています。 次の例を使用して、これがどのように機能するかを見てみましょう。

function Point(x, y) {    this.x = x;    this.y = y; } var p1 = new Point(1, 2);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

new Point(1, 2)



呼び出しが発生すると、V8は非表示のクラスC0



作成します。



最初の非表示クラスC0



これまでのところ、コンストラクターが実行される前でも、 Point



オブジェクトにはプロパティがないため、クラスC0



空です。



Point



関数の最初のコマンドが実行されるとすぐに、V8はC0



基づく2番目の隠しクラスC1



を作成します。 C1



は、プロパティx



が見つかるメモリ内の位置（オブジェクトポインタを基準とする）を示します。 この場合、プロパティxはオフセット 0に格納されます。つまり、メモリ内のPoint



オブジェクトを連続バッファーと見なす場合、最初のオフセットはプロパティx



対応します。 さらに、V8はクラスC1



への遷移に関する情報をクラスC0



追加します。これは、プロパティx



がPoint



オブジェクトに追加された場合、非表示のクラスをC0



からC1



変更する必要があることを示します。 下の図に示すように、 Point



オブジェクトの非表示クラスは、 1



クラスになりました。





オブジェクトに新しいプロパティが追加されるたびに、新しい非表示クラスへの移行に関する情報が古い非表示クラスに追加されます。 非表示のクラス間の遷移は、同じように作成されたオブジェクトが同じ非表示のクラスを持つことができるため、重要です。 2つのオブジェクトに共通の非表示クラスがあり、同じプロパティが追加された場合、遷移により、両方のオブジェクトが同じ新しい非表示クラスとそれに付随するすべての最適化されたコードを受け取ることが保証されます。



this.y = y



コマンドがthis.y = y



、このプロセスが繰り返さthis.y = y



（これも、上記のコマンドでx



プロパティを追加した後、 Point



関数内で行われます）。



ここで、新しい非表示クラスC2



が作成され、遷移情報がクラスC1



追加されます。これは、 y



プロパティがPoint



オブジェクト（これは既にx



プロパティを含むオブジェクト）に追加されると、オブジェクトの非表示クラスがC2









オブジェクトにyプロパティを追加した後のC2クラスの使用への移行



非表示のクラス間の遷移は、オブジェクトにプロパティが追加される順序に依存します。 このサンプルコードを見てください。

 function Point(x, y) {   this.x = x;   this.y = y; } var p1 = new Point(1, 2); p1.a = 5; p1.b = 6; var p2 = new Point(3, 4); p2.b = 7; p2.a = 8;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様の状況で、オブジェクトp1



とp2



が同じ隠しクラスと隠しクラスの同じ遷移ツリーを持つと仮定できます。 ただし、実際にはそうではありません。 まず、プロパティa



オブジェクトp1



に追加され、次にプロパティb



追加されます。 プロパティb



最初にp2



に追加され、次にb



追加されます。 その結果、オブジェクトp1



とp2



には異なる非表示クラスがあります-非表示クラス間の異なる遷移パスの結果です。 このような場合、隠されたクラスを再利用できるように、動的プロパティを同じ順序で初期化することをお勧めします。

組み込みキャッシュ

V8は、組み込みの呼び出しキャッシュと呼ばれる別の手法を使用して、動的に型指定された言語の実行を最適化します。 組み込みキャッシュは、同じメソッドの繰り返し呼び出しが同じタイプのオブジェクトを使用して発生する傾向があるという観察に基づいています。 詳細については、 こちらをご覧ください 。 上記の資料を読みながら、これを深く掘り下げる時間がない場合は、ここで組み込みキャッシュの概念を簡単に説明します。



それでは、これらはすべてどのように機能しますか？ V8は、最近呼び出されたメソッドにパラメーターとして渡したオブジェクトタイプのキャッシュを保持し、この情報を使用して、将来パラメーターとして渡されるオブジェクトのタイプに関する仮定を行います。 V8がメソッドに渡されるオブジェクトのタイプについて正しい仮定を立てることができた場合、オブジェクトのプロパティにアクセスする方法を見つけるプロセスをスキップし、代わりに、オブジェクトの非表示クラスへの以前の呼び出しから保存された情報を使用できます。



隠しクラスと組み込みの呼び出しキャッシュの概念はどのように関連していますか？ オブジェクトのメソッドが呼び出されると、V8エンジンは、特定のプロパティにアクセスするためのオフセットを決定するために、そのオブジェクトの非表示クラスにアクセスする必要があります。 同じ隠しクラスへの同じメソッドの2回の呼び出しに成功した後、V8は隠しクラスにアクセスする操作を省略し、プロパティのオフセットに関する情報をオブジェクトポインター自体に追加します。 今後このメソッドを呼び出すと、V8 は非表示クラスが変更されていないと想定し、非表示クラスへの以前の呼び出し後に保存されたオフセットを使用して、特定のプロパティのメモリアドレスに直接移動します。 これにより、コードの実行速度が大幅に向上します。



ビルトインコールキャッシングも、同じタイプのオブジェクトが共有の非表示クラスを使用することが非常に重要な理由です。 同じタイプの2つのオブジェクトを作成しますが、異なる隠しクラス（上記の例のように）を使用すると、V8は組み込みキャッシュを使用できません。オブジェクトが同じタイプであっても、対応する隠しクラスには異なるオフセットが割り当てられるためです。プロパティ。





同じタイプのオブジェクトが表示されますが、それらのプロパティaとbは異なる順序で作成され、異なるオフセットを持っています。

マシンコードへのコンパイル

水素グラフが最適化されると、クランクシャフトはそれをリチウムと呼ばれる低レベルのビューに変換します。 ほとんどのリチウム実装は、システムアーキテクチャに依存しています。 たとえば、このレベルでは、レジスタが割り当てられます。



その結果、リチウム表現はマシンコードにコンパイルされます。 次に、オンスタック交換（OSR）と呼ばれる処理が行われます。 プログラムが多くの時間を費やすメソッドをコンパイルおよび最適化する前に、最適化されていないオプションを使用する必要があります。 次に、作業を中断することなく、V8はコンテキスト（スタック、レジスター）を変換するため、最適化されたバージョンのコードに切り替えることができます。 他の最適化に加えて、V8が最初にコードを埋め込むことを考えると、これは非常に難しいタスクです。 これを実行できるエンジンはV8だけではありません。



最適化が失敗した場合はどうなりますか？ これに対する保護があります-いわゆる最適化解除。 これは逆変換を目的としており、エンジンと最適化の基礎によって行われた仮定が現実と一致しなくなった場合に、システムを最適化されていないコードの使用に戻します。

ガベージコレクション

ガベージコレクションの場合、V8は従来の「マークアンドスイープ」系図アプローチを使用して、前世代のコードをマークおよびクリアします。 マーキング段階では、JavaScriptの実行を停止します。 ガベージコレクターによって作成されたシステムの負荷を制御し、コードの実行をより安定させるために、V8はインクリメンタルマーキングアルゴリズムを使用します：ヒープ全体をバイパスする代わりに、ヒープの一部のみをバイパスして、可能なすべてをマークしようとします。 その後、通常のコード実行が再開されます。 ヒープ上のガベージコレクターの次のパスは、前のガベージコレクターが終了したところから始まります。 これにより、通常のコード実行中に非常に短い一時停止が可能になります。 既に述べたように、個々のスレッドはメモリクリーニングフェーズに関与しています。

点火とTurboFan

今年のV8バージョン5.9のリリース。 新しいコード実行パイプラインが導入されました。 さらに、このパイプラインを使用すると、テストではなく実際のJavaScriptアプリケーションで、パフォーマンスの大幅な向上と大幅なメモリ節約を実現できます。



新しいシステムは、Ingnitionインタープリターと最新のTurboFan最適化コンパイラーに基づいています。 これらの新しいV8メカニズムの詳細は、 この記事に記載されています。



V8 5.9のリリースに伴い、完全なコード生成とクランクシャフト（2010年以降V8で使用されてきたテクノロジー）は適用されなくなります。 V8チームは新しいツールを開発し、新しいJavaScript機能に対応し、これらの機能をサポートするために必要な最適化を実装しようとしています。 新しいテクノロジーへの移行と古いメカニズムのサポートの拒否は、よりシンプルで管理しやすいアーキテクチャーに向けたV8の開発を意味します。









JSのブラウザーとサーバーのユースケースのパフォーマンスベンチマークの改善



これらの改善はほんの始まりにすぎません。 新しいIgnitionおよびTurboFanベースのコード実行パイプラインは、JavaScriptのパフォーマンスを改善し、V8をより経済的にするさらなる最適化への扉を開きます。



V8の機能の一部を確認し、コードを最適化するためのヒントを提供します。 ちなみに、このすべては、上で説明した内容から推測することができます。

V8のJavascript最適化アプローチ

1. オブジェクトのプロパティの順序 。 オブジェクトのプロパティは常に同じ順序で初期化します。 これは、同じ非表示オブジェクトが同じ非表示クラスを使用し、その結果、最適化されたコードを使用するために必要です。
   
   
2. 動的プロパティ 。 オブジェクトのインスタンスを作成した後にオブジェクトにプロパティを追加すると、非表示のクラスが変更され、オブジェクトで以前に使用されていた非表示のクラスに対して最適化されたメソッドが遅くなります。 プロパティを動的に追加する代わりに、オブジェクトのコンストラクターでプロパティを割り当てます。
   
   
3. 方法 同じメソッドを複数回呼び出すコードは、複数の異なるメソッドを1回呼び出すコードよりも高速に実行されます（組み込みキャッシュのため）。
   
   
4. 配列 キーが連続番号ではないスパース配列を避けます。 スパース配列、つまり要素の一部が欠落している配列は、ハッシュテーブルとしてシステムによって処理されます。 このような配列の要素にアクセスするには、より多くのコンピューティングリソースが必要です。 さらに、大規模な配列のメモリの早期割り当てを避けるようにしてください。 必要に応じてサイズを大きくするとよいでしょう。 最後に、配列内の要素を削除しないでください。 このため、それらはまばらな配列になります。
   
   
5. 番号 V8は、32ビットを使用してオブジェクトへの数値とポインターを表します。 1ビットを使用して、32ビット値がオブジェクトへのポインター（フラグ-1）であるか、整数（フラグ-0）であるかを判別します。これは、小整数（SMall Integer、SMI）と呼ばれます。その長さが31ビットであること。 数値の保存に31ビット以上が必要な場合、V8は数値をパックして倍精度数値に変換し、その数値を格納する新しいオブジェクトを作成します。 数値をJSオブジェクトにパッキングする面倒な操作を避けるために、可能な限り31ビットの符号付き数値を使用するようにしてください。
   
   

まとめ

SessionStackでは、JSコードを記述する際に上記の原則に従うよう努めています。 V8の内部メカニズムがどのように機能するかを少し理解し、上記の内容を考慮して、プログラムの品質とパフォーマンスを改善できることを願っています。



親愛なる読者！ JSコードを最適化するためのヒントを教えてください。