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エンジンの仕事はどうなる？
- V8のGCは、世代別GC(Garbage collection (computer science))
- 世代別GCの考え方
- たいていのオブジェクトは、早死に／長生きのどちらか。
- 長生きオブジェクトは生存のチェックが不要。どうせ生きてるから。
- 世代別GCでは新しく生じたオブジェクトだけ注意していればよくなる。
- V8が巨大なobject heapにもスケールできてるかを検証してみるためにベンチマークを１つ作った。
- V8 Benchmark Suite
- 現在Ver.4で、Splayが新作。
- Splayがやってること
- 巨大なSplay treeを作成
- 作成したSplay treeを新規ノードをどんどん追加
- 古いノードをSplay treeからどんどん削除
- ベンチマーク結果からわかること
- V8がかなり早く、ノードへのメモリ割り当てと不使用メモリの再利用を実行してること。
- グラフよりわかること
- working setを5MBから35MBまで変化させても、パフォーマンス低下は17%以下
- 35MBは現在の主要なウェブアプリに必要なメモリと比べても大きい。将来の重量級ウェブアプリにも対応できる
- コメント欄
