読者です 読者をやめる 読者になる 読者になる

以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

M.Ager,K.Lund「Scaling JavaScript to Large Web Applications」

斜め読み

Scaling JavaScript to Large Web Applications


Chromium BlogのV8の処理能力自慢エントリ。
V8は重量級ウェブアプリで必須の大量のオブジェクト発生/死滅にも対応できる、GCとしては世代別GCを導入、性能チェックのためにSplayというベンチマークを作った、という主旨
スケールとか、ヒープとか自分の理解の怪しい言葉が出たが、なんとか斜め読み。

以下斜め読んだ内容
  • V8は、スケールできるように設計
  • 複雑になったウェブアプリでは、オブジェクトの数も増大しがち。これへの対応がjsエンジンに必要
    • メモリ管理への圧力が増加
    • オブジェクトへのメモリ割り当て、オブジェクトの再利用。これを効率的に処理することが必要
  • "multi-process architecture"
    • chromeの実装のこと。browser、renderer、plug-insが別プロセス。さらにタブごとに別プロセスになる
  • "multi-process architecture"を実装しない他のブラウザでのjsエンジンの仕事はどうなる?
    • 一例。タブ1でgmail、別のタブでjsのベンチマーク実行してみる
      • 二つのタブ内で生じてるオブジェクトは全て、1つのオブジェクト用のメモリ領域(object heap)に割り当てられる
      • ベンチマークの実行は別タブのgmailの処理と平行して行われる
  • V8のGCは、世代別GC(Garbage collection (computer science))
  • 世代別GCの考え方
    • たいていのオブジェクトは、早死に/長生きのどちらか。
    • 長生きオブジェクトは生存のチェックが不要。どうせ生きてるから。
    • 世代別GCでは新しく生じたオブジェクトだけ注意していればよくなる。
  • V8が巨大なobject heapにもスケールできてるかを検証してみるためにベンチマークを1つ作った。
  • V8 Benchmark Suite
    • 現在Ver.4で、Splayが新作。
  • Splayがやってること
    • 巨大なSplay treeを作成
    • 作成したSplay treeを新規ノードをどんどん追加
    • 古いノードをSplay treeからどんどん削除
  • ベンチマーク結果からわかること
    • V8がかなり早く、ノードへのメモリ割り当てと不使用メモリの再利用を実行してること。
    • グラフよりわかること
      • working setを5MBから35MBまで変化させても、パフォーマンス低下は17%以下
      • 35MBは現在の主要なウェブアプリに必要なメモリと比べても大きい。将来の重量級ウェブアプリにも対応できる
  • コメント欄
    • 盛り上がってないけど、IEや他のブラウザでSplayを実行したときのスコアを報告してる日あり。自分はIE6でベンチマークのページ開いたらRegExpのベンチマークの所で固まった。