GC CompartmentsTechnology Introduction

by Tomoya ASAI (aka. dynamis)

Fractal Firefox Background Image: http://r.dynamis.jp/fractalfx

Topics

JavaScript の高速化

Garbage Collection

Compartments

＊＊＊＊分離との違い

JavaScript の高速化

AreWeFastYet?

http://arewefastyet.com/ Sunspider ベンチでも Nitoro に追いついたところです

JavaScript 高速化

SpiderMokey (Fx2) SM (Fx3) TraceMonkey (Fx3.5) TM (Fx3.6) JM (Fx4)

ベンチマーク Trace 不可コード Trace 可能コードベンチマークは SpiderMonkey を基準とした場合、Firefox 4 については現状

3.3 倍

2.6 倍

1.3 倍

3 倍程度？

Kraken

ベンチマークも無意味ではないが...

開発時の指標は何か必要だけど何の計測か正しく理解してないと...

もっと違う高速化だってあります

ベンチに反映されないものも...JavaScript 以外の高速化もですが

Garbage Collection

JavaScript のゴミ掃除

使わなくなったオブジェクト

メモリ領域を回収

これまでの Firefox

全部 1 つのヒープ領域に

全タブのデータが毎回対象に...

ブラウザ UI 側も一緒に...

要するにこれまでは

無駄が多かった (＞＜)

関係あまりないものは別領域に分離しよう！

Compartments

メモリ領域を分割する

ドメイン毎に分割

ドメイン間の参照は少ない！

UI (Chrome) も分離

UI の変化は少ない！

これからの Firefox

必要なところだけ GC

待ち時間 (ひっかかり) が減る

キャッシュ効果も効きやすく

同時に使うものが同じ領域に

プロセス分離に近い安全性

CPU がやるかアプリがやるか

Wrapper

ドメイン間の操作を制御

これまでは動的にドメイン確認

アクセス元とアクセス先を比較

これからは静的に判断可能に

プロパティによって判断可能

要するに高速になります

ところでこの話...

プロセス分離と似てない？

ドメイン毎に分離するわけでしょ？

プロセス分離との違い

セキュリティチェックの主体

by CPU or by アプリ

使用するメモリ

プロセス分離はメモリも必要

アクセス速度

プロセス間通信は超重たい！

Mozilla の現実解はプロセス分離ではなく

Compartments

少なくとも今のところは...

プロセス分離はホントに必要？

Referencesfor more information...

reference元ネタの解説記事 (翻訳と原文)

http://firefoxhacks.at.webry.info/201010/article_3.htmlhttp://andreasgal.wordpress.com/2010/10/13/compartments/開発計画段階のメモ

https://wiki.mozilla.org/JavaScript:SpiderMonkey:GC_FuturesBugzilla の関連バグ

https://bugzilla.mozilla.org/show_bug.cgi?id=compartmentshttps://bugzilla.mozilla.org/show_bug.cgi?id=558861https://bugzilla.mozilla.org/show_bug.cgi?id=mt-wrappers