Firefoxは常に単一プロセスの構築モデルを使用しています。 並列化の分野での変化への関心は、Chromeブラウザーの出力に拍車をかけました。Chromeブラウザーは、インターフェースに1つのプロセスを使用し、Webページのコンテンツを操作するために別のプロセスを使用しました。 (それでも、Chromeの6か月前に、いくつかのプロセスがInternet Explorer 8の使用を開始しました。)すぐに、他のいくつかのブラウザーがChromeの例に従い、MozillaはElectrolysisプロジェクトを立ち上げ、Geckoエンジンをいくつかのプロセスを使用するように適合させました。
Mozillaがブラウザを構築するために同様のモデルに切り替える理由は何ですか? まず第一に、それはパフォーマンスと応答性です。 主な目標は、特に大きなページの読み込み、Webフォームへの入力、またはページ要素でオーバーロードされたスクロールなど、標準操作で現れるジャンクを減らすことです。
今日の応答性は、パフォーマンスよりもいくぶん重要です。 作業の一部は、 Snappyプロジェクトの一部として実施されました。 主なタスクは次のとおりです。
- メインプロセスが応答し続けるように、長い操作を別のスレッドに移動する。
- メインプロセスがディスク操作によってブロックされないように、非同期I / Oを実装します。
- 長い操作をパーツに分割し、その間にイベントループを配置します。 この例は、パラレルガベージコレクションです。
これらのタスクのうち最も簡単なものはすでに完了していますが、今では最も難しいものが残っています。
別のニーズは安全性です。 現在、Firefoxで未解決のバグを検出した後、攻撃者はユーザーのマシンで任意のコードを実行できます。 セキュリティの問題を解決するために多くのテクニックとテクニックが使用されていますが、最も効果的なのはサンドボックスでコードを実行することです。
ただし、現在のシングルプロセスFirefoxアーキテクチャをサンドボックスに配置することは効果的ではないようです。サンドボックスモードは、プロセスが実行すべきでないアクションを実行するのを防ぐだけであり、現在のFirefox組織(特に多くの追加を伴う)にはネットワークへの幅広いアクセスが必要ですおよびファイルシステム。 マルチプロセスFirefoxは、サンドボックスモードでの各Webコンテンツプロセスの動作に深い制限を提供します。これにより、開発者が期待するように、ブラウザーの脆弱性の数が減ります。 ファイルシステムへのアクセスは、メインプロセスによって制御されます。
さらに、開発者は、 Firefoxが世界で最も安定したブラウザーであるにもかかわらず、Fire Foxの安定性を高めようとしました 。 ブラウザー全体をドロップする代わりに、特定のタブまたは要素を担当するプロセスのみが該当します。
すでに何が起こったかを見ることができます。 これを行うには、ブラウザのナイトリービルドをダウンロードし 、
browser.tabs.remote
パラメータを
true
設定するだけ
true
。 開発者は、新しいプロファイルを作成することを強くお勧めします。
about:memory
すでに個々のプロセスの消費量を表示しています。
これがFirefoxマルチプロセスウィンドウの外観です。 タブの下線付きの名前は、そのコンテンツが別のプロセスで処理されるという事実を反映しています。
そのため、別のタブが表示されます。
ほとんどの人が持っている最初の質問は、RAMの消費に関連しています。 ユーザーは、プロセスが増えるとメモリが増えることを確信しています。 開発者は、いくつかのプロセスに共通する多くの最適化と特定のタイプのキャッシュの導入を約束します。 それらの1つに1つのプロセスによって書き込まれたデータがある場合、他のプロセスはそのメモリ領域に新しいデータを作成する代わりに、その存在をチェックし、このキャッシュからのデータを使用できます。 このようなモデルを使用すると、セキュリティを強化し、パフォーマンスを維持できます。
MemBenchベンチマークを使用し、50個のタブを開いた後、通常のシングルプロセッサバージョンと比較してメモリ消費はわずか10メガバイト増加しました(974メガバイトから984メガバイト)。 時間が経つにつれて、この差は最小になります。
現時点では、マルチプロセスFirefoxがいつリリース段階に到達するかは不明のままです。開発者には多くの作業が必要です。 新しいアーキテクチャの詳細は、 Bill McCloskeyの出版物に反映されています。