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

Mozilla Flux

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

Firefox 48から一部環境でマルチプロセス機能(e10s)が有効化 Firefox 53で完全実施へ(追記あり)

Fx情報

アドオンをインストールした環境は対象外

Firefox 48リリース版では、ついにマルチプロセス機能(e10s)の有効化が開始される。ただし一部環境では、という留保つきだ。有効化された環境では、Webページを閲覧中にクラッシュやハングが発生しても本体が巻き添えにならないので、安定性が向上する。

対象にならない環境を挙げておくと、まずは近々サポート対象外となるOS X 10.6/10.7/10.8のほか、クラッシュ率上昇の問題を抱えるWindows XP(Bug 1275039)はまるまる除かれる。また、アドオンをインストールしている場合も対象外となり(Bug 1250744)、e10sが有効の状態でアドオンをインストールすると、Firefoxの再起動によりe10sが無効になる(Bug 1232274)。さらに、アクセシビリティツールが動作している場合(Bug 1198459Bug 1260190Bug 1277882)やRTL言語*1ロケールの場合(Bug 1234673Bug 1243882)もe10sは有効にならない。*2

注意が必要なのは、Windows上でテキストやその他の項目を拡大する設定にしていることも、「アクセシビリティツールが動作している」とみなされる点だ。アドオンを入れていないのにe10sが有効にならないときは、ここで引っかかっている可能性がある。また、e10sが有効なときは以前紹介したAsync Pan/Zoom(APZ)機能も有効になる。Firefox本体がキビキビと動作する反面、Flashプラグインの利用時に問題が生じるかもしれない。

Firefox 48のリリース直後、e10sが有効化されるのは対象環境のリリース版ユーザーの1%に制限される(Bug 1284958)。これを数に直すと全Beta版ユーザーの数とほぼ等しくなることからこの割合が選ばれた。Beta版に関してはFirefox 44のころから継続的にe10sのテストが続けられており、Firefox 48 Betaではユーザーの半数について開発サイクルの全期間(6週間)にわたりe10sが有効化されている。つまり単純計算では、上記の1%はその2倍の数となるわけだ。Mozillaはここで様子を見て、問題がなければ対象ユーザーの範囲を広げていく。非対象環境を除くと、全リリース版ユーザーの約41%にe10sが提供される見込みだという。

7年をかけた一大プロジェクト

e10sの開発には紆余曲折があった。当ブログの記事を振り返ってみると、Firefox.nextでコンテンツとクロームのプロセスを分離 - Mozilla Fluxが初出のようだ。2009年5月に開発計画が公表されており、今から7年も前のことになる。単一であったFirefoxのプロセスを、ユーザーインターフェイス担当の親プロセス(chromeプロセス)とコンテンツ(タブ)担当の子プロセス(contentプロセス)に分けるこのプロジェクトは、水を水素と酸素に電気分解することになぞらえてElectrolysisと呼ばれるようになった。e10sは冒頭のEと末尾のsの間に10文字が挟まっていることを踏まえた略称だ。

Firefoxのマルチプロセス化はフェーズ2へ - Mozilla Fluxでは、安定性の向上、マルチコアプロセッサを活用したパフォーマンスアップおよびセキュリティの強化がe10sのメリットであること、ただしセキュリティの強化につながるサンドボックス化は将来の課題であることに言及していた。2009年6月の段階で、既にe10sの基本線は引かれていたことがうかがえる。その後、プラグインの別プロセス化を達成した時点でFirefox 4の完成を優先することになったものの、2011年3月にFirefox 4がリリースされ、同年7月時点で開発が本格化していた。

ところが、Electrolysis(e10s)は終わるのか? - Mozilla Fluxで紹介したように、2011年11月になってe10sプロジェクトは突然活動が停止されてしまう。開発の成果を得るには時間がかかりすぎるので、まずはより小規模な案件に集中して取り組むというのがその理由だ。このとき、プロジェクトは停止と言いつつ実質的に中止されたのではないか、との意見も多かったように記憶している。

しかし、e10sプロジェクトは再開された。Mozilla may bring the multi-process architecture Electrolysis (e10s) back from the dead - gHacks Tech Newsという記事が出たのが2013年4月のこと。記事から間を置かずに開発者が再開を宣言した。同年12月には、Firefoxのコードレビューの際、e10s互換性のチェックが必須化され、再度のプロジェクト停止はほぼあり得ない状況となった。

開発再開からも既に3年の月日が流れた。それだけFirefoxに大改造を施すのがたいへんだったわけだが、ようやくゴールが見えてきた。

完全実施はFirefox 53の予定

最新のロードマップによれば、Firefox 50(2016年11月8日〔米国時間〕リリース予定)の時点で、アクセシビリティツールが動作している場合やRTL言語ロケールの場合、それにタッチスクリーン環境においてe10sが有効化される。他方、Windows XPのサポート時期は明らかにされていない。FirefoxとしてXPのサポートをどこまで続けるかという議論がなされている状況からすると、e10sは無効のままということもあり得る。

また、Firefox 51(2017年1月24日リリース予定)以降、順次アドオンがインストールされた環境でもe10sが有効化されていき、Firefox 53(2017年4月下旬リリース予定)で全面的に有効化される。Firefox 51の時点では、WebExtensionsベースの拡張機能に加え、ホワイトリストに掲載された従来型アドオン*3が対象となる。Firefox 52でリストの対象を広げ、Firefox 53でリストを廃止するという流れだ。早くもFirefox 49 Beta版ではホワイトリストのテストが始まり(Bug 1282120)、当初は9つのアドオンがリストに載る。

Mozilla Add-ons(AMO)に登録済みでユーザー数の多いアドオンに関しては、Are we e10s yet?でe10sへの対応状況を一覧できる。unknownの項目が多くて驚くかもしれないが、Firefox側に互換性を維持するためのライブラリ(e10s shims:Bug 1063156)が搭載されているので、現時点で動作するものも多い。

Firefox 53でe10sが初期設定において有効化されるようになったら、その先に待っているのはcontentプロセスの複数化だ。該当プロジェクトはe10s-multiと呼ばれ、その計画によれば、まずはcontentプロセスを2つにする。このとき、Service Workerには独立したプロセスが与えられるようになるらしい。当面の目標はcontentプロセスを5つに増やすことだが、単純にプロセスを増やすとメモリ消費量も増えてしまうため、メモリの利用状況の最適化を図り、様子を見ながらプロセスを増やしていくことになる。

強制有効化の設定

最後に、e10sを強制的に有効化する方法を紹介しておこう。既にLatest topics > Firefoxのマルチプロセス機能を強制的に有効化する方法まとめ - outsider reflexにまとめられているが、about:configの画面でbrowser.tabs.remote.force-enableをtrueに設定することで、「アクセシビリティツールが動作している」か否かのチェックを回避できる。また、extensions.e10sBlocksEnablingextensions.e10sBlockedByAddonsを両方falseに設定することで、「アドオンがインストールされている」か否かのチェックを回避できる。原則として開発者向けだが、e10sの安定性やAPZのパフォーマンスを重視するユーザーにとっても選択肢となるだろう。

(16/07/31追記)
E10s/Status/July22 - MozillaWikiによれば、e10sが対象環境のリリース版ユーザーの5%に展開されるのが8月15日、100%に展開されるのが8月22日となる見込みだ。また、本記事執筆後、アクセシビリティツールが動作している場合のe10s有効化はFirefox 51へと延期された

なお、本文を若干修正した。

(16/08/06追記)
前回追記後に出たWhat’s Next for Multi-process Firefox | Future Releases和訳)が、e10sに関し3つの新情報を提供している。

1点目。e10sが有効化される環境に、WebExtensionsベースの拡張機能またはホワイトリスト掲載の従来型アドオンがインストールされていることを含める時期を、Firefox 50に前倒しする。その前提として、Firefox 49リリース版でも少数の従来型アドオンは実験的にe10s有効化の対象となる。仮にBeta版のとおりであれば、その従来型アドオンは、Greasemonkey、Download YouTube Videos as MP4、Video Download Helper、Lightbeam、Flashblock、Adblock Plus、uBlock Origin、Emoji Cheatsheet、Awesome Screenshot Plusの9つになるはずだ(Bug 1247497参照。ただし古いバージョンは除く)。他方、ホワイトリストの撤廃時期(=e10sの完全実施時期)については上記記事中で触れられていない。

2点目。本文で触れたe10s-multiを2017年前半のうちに実現する。これがcontentプロセスを幾つにすることを指すのかまでは明らかにされていない。そして、e10s-multiと並行してプロセスのサンドボックス化も導入する。ここでは、Mozillaがサンドボックス化にChromiumのコードを利用していることが重要になってくる。GoogleがChrome 50でWindows XP/Vistaのサポートを打ち切ったため、Mozillaは現状のサポート環境を維持しようとすれば、Chrome 49相当のコードしか使うことができない(Bug 1287426)。Windows Vistaの延長サポートが2017年4月11日に終了することも考慮に入れると、サンドボックス化の話はFirefoxがESR以外でXP/Vistaのサポートを打ち切る布石かもしれない。

3点目。e10s-multiおよびプロセスのサンドボックス化が実現した後、拡張機能ごとにサンドボックス化されたプロセスを割り当てる。これはもともとAdd-on SDKベースの拡張機能に関して計画されていた内容である。しかし、今のMozillaはWebExtensionsを強く推す立場だ。元の計画を、コストをかけてXUL/XPCOMベースの拡張機能まで対象にするよう広げるとは思えない。つまり、独立プロセスでサンドボックス化されるのは、WebExtensionsベースの拡張機能に限定されるだろう。

以上のほか、E10s/Status/Aug05 - MozillaWikiによれば、2016年8月15日時点で、e10sは対象環境のリリース版ユーザーの10%に展開されることになった。前回追記時よりも前倒しされており、Firefox 48でのe10s展開は順調なようだ。

なお、再び本文を若干修正し、注を1つ加えた。

*1:RTLはRight-to-leftの略で、アラビア語やヘブライ語のように右から左に記述するのがRTL言語だ。

*2:このほか、タッチスクリーン環境も対象外のようだ。

*3:XUL/XPCOMベースのものとAdd-on SDKベースのものを含む。