FluxMozilla関係の情報に特化したブログです。マルチプロセスFirefoxのコンテント・プロセス(Webページの表示部分)とクローム・プロセス(UI部分)を分離し、コンテント・プロセスをマルチプロセス化する流れは、既定路線と思われていた。Electrolysis(e10s)プロジェクトの先行きが不透明になったことで、雲行きが怪しくなっている。直近の性能向上を優先』で報じられているとおりだ。future」と表現している。e10sプロジェクトの活動を当面の間停止するという意味だ。Mandel氏によれば、e10sは対象が広汎にわたるため、開発の成果を得るには時間がかかりすぎる。そこで、活動をいったん停止して、より小規模な案件に集中して取り組むという。案件の具体例として、プラグインの別プロセス化(OOPP)、Placesデータベースの最適化、JavaScriptにおける増分ガベージコレクションが挙げられている。いずれも、Firefoxの応答性を改善するために開発リソースを投入すべき分野とされているわけだが、その中にFirefoxのマルチプロセス化の第一歩ともいえるOOPPが含まれているのは興味深い。Mandel氏は、e10sプロジェクトを停止する理由として、新しいマルチプロセス環境でアドオンが機能するかどうかを調査し、問題を解決する必要があるとも述べているが、これはあくまで既存のアドオンを指しているとみられる。動きe10sプロジェクトの活動停止は、Firefoxの開発責任者クラスでも事前に連絡を受けていなかった。PDT』というスレッドである。Sicore氏から重大発表がもたらされた。Sicore氏いわく、UIの無応答、ハング、スクロールやビデオ再生中のもたつきといった問題がユーザーから報告され続けており、長期的に大量のリソースが必要なe10sプロジェクトをいったん止め、CrashKillのような特別プロジェクトを起ち上げて、応答性の問題に対処するという。O'Callahan氏といった中心的な開発者たちが、e10sなしで問題をすべて解決できるのかと即座に疑問を呈しており、トップダウン的な意思決定が行われたことが窺われる。スレッドが伸びている理由は、e10sとはあまり関係がない。Sicore氏が、「いつどこでSQLデータベースを使うかについて、つらい決断をしなければならない。SQLiteの代わりになるものを検討しなければならない」と述べたため、SQLiteを捨てるべきか否かで激しい議論が交わされたのだ。Mobileはe10sから離脱Android版FirefoxがネイティブUIを採用したニュースは、ご存じの方も多いだろう。Firefoxの起動時にGeckoとXULを用いず、Javaを使うわけだ。Android』で説明しているところによると、GeckoとXULは別スレッドに読み込まれ、ネイティブUIとメッセージのやりとりをする。このやりとりは、e10sではなく、より軽量なアーキテクチャのシステムを通じて行われるという。Overviewで読むことができる。面白いことに、ネイティブUIの採用によってもXULが部分的に残る一方で、e10sはあっさりと捨てられてしまった。この動きは今のところAndroid版に限られるものの、今後進出するプラットフォームでも同じことが起きるだろう。Mobile全体の方針と考えたほうがよさそうだ。SDK(旧Jetpack)の開発には最優先事項が3つあった。うち1つがアドオンの別プロセス化、つまりe10sの導入である。そこに降って湧いたようなe10sプロジェクトの活動停止。Piroさんが『e10sオワタ』で指摘されているように、開発チームにとってはしごを外された形だ。SDKはリリース時期こそFirefoxの高速リリースサイクルとリンクしているものの、独立したプロダクトであり、開発をどう進めるかも自分たちで決めることができる。add-on"'s』にまとめられている。SDKベースのアドオンを別プロセス/スレッド/ワーカーで動作可能にするための開発は継続するそうだ。アドオンを独立したスレッドで動作させるプロトタイプについては、作業に着手するかどうかを検討するとしている。デスクトップ版で復活の可能性あり今回の動きを整理しよう。SDKの開発チームが対策を協議した。Mobileがe10sから離脱することを決めたのは、Sicore氏による表明よりもずっと前のことだ。Mobileが離脱したため、デスクトップ版でもプロジェクトの再検討を迫られたという見方もできるだろう。いえ、e10sを終わらせるには開発を進めすぎたのではないだろうか。これまでにかかったコストをすべて埋没費用で片付けられるのか。コンテント・プロセスとクローム・プロセスの分離は、Webブラウザの主流だ。Explorerも間違っていることになるし、Safariに至ってはわざわざWebKit2で間違った道を追いかけたことになってしまう。Firefoxの応答性は、特別プロジェクトを通じて改善されてゆくのだろう。抜本的な対策としてのe10sの意義は失われていない。複数のタブを使うことがあたりまえで、Webアプリを「常駐」させることも珍しくなくなった現在、Webブラウザが丸ごとクラッシュする事態は非常にまずい。Mozillaが当面は対症療法を採用するとしても、根治の特効薬の入手を諦めるとは思えない。それに、Webコンテンツをサンドボックスに閉じ込める手法は、セキュリティ面で有効性が実証されている。別の手法を研究して実装するのは得策ではなく、この1点だけでもMozillaがe10sプロジェクトを継続する理由として充分といえよう。さしあたっての課題を解決したら、デスクトップ版Firefoxではe10sプロジェクトが再開するだろうし、また、そうあるべきだと考える。はてなブログProMozilla関係の情報に特化したブログです。ZoneMoz-Fxりんごが好きなのでぃすとりかごとなり。@abp_jpUnreviewednorah'#Firefox更新情報Wikiブログ日々のつぶやきスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。