Mozilla Flux

Mozilla関係の情報に特化したブログです。

Firefoxのマルチプロセス化はフェーズ2へ

以前紹介したとおり、Firefox.nextはブラウザのユーザーインターフェイス(UI)を表示するプロセス(クロームプロセス)と、Webコンテンツを表示するプロセス(コンテンツプロセス)を分離する計画になっている。コンテンツプロセスは、「プロセス・オン・デマンド」となり、タブごとにプロセスを割り当てられるようになる。ただ、Google Chrome(以下Chrome)やIE8と同じにするかどうかはまだ確定しておらず、メモリ効率を考えてドメイン単位でのプロセス割り当てにとどめる可能性もある。

他方、mozilla.dev.platformの『Electrolysis update: out-of-process plugins and more』を見ると、プラグインに独自のプロセスを付与することは確実なようだ。Safari 4でも採用されている手法だが、プラグインを独立させることで、Firefox本体がクラッシュに巻き込まれるのを防ぐことができる。

このマルチプロセス化のプロジェクトは、「Electrolysis(電気分解)」と呼ばれ、現在6人以上のメンバーが関与しているが、その一人でFirefoxの主要開発者でもあるBenjamin Smedberg氏によれば、マルチプロセスの恩恵は次の三点だという(『Electrolysis: Making Mozilla Faster and More Stable Using Multiple Processes』)。

  • 安定性の向上
  • マルチコアプロセッサを活用したパフォーマンスアップ
  • セキュリティの強化

ただ、セキュリティサンドボックスの実装は将来の課題とし、クロームプロセス/コンテンツプロセス/プラグインプロセスの分離を優先する。そして、必要なコードすべてを一から作るのでは時間がかかるため、Chromium(Chromeのベースとなるオープンソースのプログラム)からIPC(プロセス間通信)に関する部分を取り入れている。なお、ネットワークライブラリ (Necko) の置換は見送られた

Electrolysisは4つのフェーズに分かれているが、フェーズ1(7月15日までの完成が目標)の開発成果を示したのが、『Multi-process Firefox, coming to an Internets near you』という記事である。

そこでは、クロームプロセスがコンテンツプロセスから分離されたことが実証されている。mozilla.comを表示させたコンテンツプロセスをコンソールから削除しても、クロームプロセスは残り、復元ボタンを押すと元のページが復活するのだ。これは、FirefoxでWebページを閲覧中にクラッシュに遭遇しても、Firefoxのフレームが生き残っていることを意味している。実際に本体に組み込まれたときは、復元ボタンではなく、「最近閉じたタブ」メニューが使われることだろう。

プラグインに関しても、上の『Electrolysis update〜』によると、Linux上で、ウィンドウモードにおける単一プラグインの単一インスタンスが独立のプロセスで動作しているという。まだNPRuntime(プラグイン向けスクリプト用ラッパー)は実装していないものの、開発メンバーのChris Jones氏いわく、実装にそれほど苦労しないだろうとのことだ。とはいえ、残るウィンドウレスモードのサポートは厄介らしい。

Development Meetingでの発表やSmedberg氏のコメントを見ると、以上の成果をWindowsでも達成した時点でフェーズ1は終了となるようだ。取り組みやすさからこの二つのプラットフォームでの開発が先行したものの、もちろんMac OS Xでも作業は行われる。

次のフェーズ2は、11月1日までの完成が目標となる。まずはネットワーク、履歴やFirefoxの設定などに取り組むとされており、どうやらコンテンツプロセスの複数化に対応していくようだ。つまり、タブごとにプロセスを割り当てても、ユーザーから見たFirefoxの動作が変わらないようにする必要があり、そのための作業を順番に進めていくのである。

ある意味当然といえるけれども、この作業をElectrolysisチーム内だけで完結させることはできない。それを典型的に示しているのが、MozillaWikiの『Multiprocess Images』で、グラフィックスチームが画像キャッシュを改良して、マルチプロセスに対応させる旨を述べたものだ。

現在の仕様のままでタブごとにプロセスを割り当てた場合、画像キャッシュもタブごとに保持することになる。それはリソース的に非常に無駄が多く、パフォーマンスも悪化する。そこで、クロームプロセス内あるは独立したプロセス内に「画像サーバー(imgServer)」を置いてキャッシュを管理し、タブ側の「画像ローダー(imgLoader)」とプロセス間通信を行う予定だ。また、パフォーマンスを考慮し、デコード済みのデータを画像サーバー側で保持して、それをクライアントに渡すことも検討されている。

このように、マルチプロセス化の取り組みはFirefox全体に大きく影響する。思わぬ障害に出くわす可能性も考えられ、フェーズ2が目標どおりの時期に終了するかどうかはわからない。その後はさらに流動的で、ポイントはTrunkに統合される時期だろう。統合直後は拡張機能の互換性が低下すると予測される。さらにマルチプロセス化すればただちにマルチコアのプロセッサ上で速くなるわけではないため、一時的なパフォーマンスの低下もありうる。そうした混乱からいかに早く抜け出せるかが重要といえる。