Firefox Hacks 翻訳日記

アクセスカウンタ

zoom RSS Mozilla 2 和訳

<<   作成日時 : 2006/10/23 23:04   >>

トラックバック 0 / コメント 9

この記事は、Brendan Eich が自分のブログ Brendan's Roadmap Updates に、2006年10月13日付けで投稿した、Mozilla 2 の翻訳である。
正直言って、訳者はバックエンドに詳しいわけではないので、誤読・誤訳の類があると思われる。特に Oink 回りには自信がない。識者諸賢のご指摘をお待ちしている。

なお、長文なので読んでる暇がない、という向きは、最後のセクション にまとめがあるので念の為。
また、脚注 は全て訳者によるものである (蛇足とも言う)。




Mozilla 2


1999年にはオープンソースの 失敗例脚注 1) だった Mozilla は、2004年からはオープンソースの 代表例 となっている。これは、大部分が Firefox の成功によるものだ。これについては、「マーケットのタイミング」で、幸運な面もあった。Microsoft が何かへまをやらかしており、Firefox がそこを突いている、という事が 2004年の夏に突然明らかになるまで、誰もがブラウザのマーケットは消滅したものと思っていたのだ。


しかし、運だけでうまくいったわけではない。Firefox のデフォルトの UI と操作性のデザインを日常的なユーザー向けのものとし、理念だけのウェブ標準のかわりに現実世界のウェブ標準に基づき、バグによる逆境にもめげず、「プラットフォーム」を作る計画的な作業(ただし、これは二次的なもので、まずアプリケーションがあった)、特に アドオン によってウェブ・デベロッパーとパワーユーザーの役に立つ、という事。これらの全てが、Firefox の成功にとって必要だったのだ。


2001 年の前半に私が manifesto脚注 2) を書いたマイルストーンリリースである Mozilla 1.0 がなければ、Firefox もまた存在しなかった、という事は特筆しておきたい。Mozilla 1.0 は 2002年の6月にリリースされ、Netscape 6 と コードの書き直し によって失った名声をついに取り戻したのだ。これによって、Firefox、Thunderbird、そしてその他の XUL アプリケーションの基盤が築かれた。


Mozilla 1.0 の技術的な金型は 1998 年後半 と 1999年に作られたものであり、ブラウザが立脚するべき API の安定版となる 1.0 の作成は、「完成」というものに向けた作業であった、と言えるだろう。それ以来、コードベースのほとんどが何らかの形で改訂されたが、それは常に追加改訂だった。「ビッグバン」はなかったのだ。


来年前半に Mozilla 1.9 の安定版ブランチとなる、現在の CVS トランクは、レンダリングにおける多大な再設計と、ここでは触れる余裕のない重要な作業の結果を含んでいる。


グラフィックの作業reflow のリファクタリング とが、この Mozilla のマイルストーン・プロセスの中でおそらく最も目に付く先進的な変化だろう。このプロセスは、「Mozilla 1.0 宣言」の時代とあまり変わりなく、コミュニティによる品質保証とパッチの貢献者に大きく依存している。彼らは、コードを充分にテストする為に、製品のアルファ・ベータ・リリースというサイクルを追いかけなければならない。このサイクルは、Firefox 3 の基盤となる 1.9 まで継続される。




さて、Mozilla は、巨大で、成熟し、極めて保守的に維持されて来た、オープンソースのコードベースだ。何か新しいものがあるだろうか?


たくさんある。多機種の相互運用とオープン・スタンダードのシステムとしてのウェブは、今や新たな戦場だ。ブラウザの競争は白熱し、技術革新が独占的な企業に占有されそうにない部分では大きな期待が持てる。


携帯デバイス界は劇的な成長を遂げているが、電源の容量と浪費の限界によってムーアの法則は一時的に無効になっている。さらに悪いことには、携帯のキャリアとデバイスメーカーによって、ほとんどのユーザーが使う全てのソフトウェアが支配され、Firefox を導入するような選択の余地はないに等しいのだ。モバイルに関する考察は別の機会に譲ろう。


デスクトップのシステムはどうだろう? 今後の 4年間で、デスクトップは、多数のコア CPU と (最初は特殊な用途だろうが、そのうちにもっと有用になる) テラフロップの GPU を搭載するようになるだろう (脚注 3) 。マルチメディアと 3D コンテンツは、高価で複雑なツールを持ち合わせていない一般人でも扱いやすいものになるだろう。そうでなければ、パワーと帯域の無駄遣いだ。3D はさておいても、検索の向上、テキストレンダリングの向上、ビデオの利便性、そしてユーザーのための全てのタスクが、これらのハードウェアサイクルを取り入れるべきだ。どんなことが起こるにせよ、それをゲームや他の独占的なソフトウェアや閉鎖的なコンテンツフォーマットだけのものにしておくのは、恥ずかしいことだ。


では、我々 Mozilla 界は何をしたらよいのだろう?


まず、我々は Mozilla 1.9 の「後に」、2008年を目標として Mozilla 2 を開発するべきだ。しかし、この開発は、早期に、来月にでも着手するべきだろう。1.9 の後に 1.10 を続けて、収穫逓減の法則に猪突猛進するべきではない。


次に、Mozilla 2 の開発が軌道に乗ってから、上記した超すごい CPU と GPU を気にする事になるだろう。私はこれについていくつか考えがあるが、別の記事のネタとして取っておく。


Mozilla 2 の大きな意義として、凍結された API 互換性からの開放がある。これによって、現在のアーキテクチャに存在する制限をなくし、古い API とその実装 を削除し、必要な API とコードを更新・改良して、ランタイムとコードサイズでの大きな勝利を実現できる。例えば、RDF をなくすこともできるだろう。Steve Yegge がユーモラスに書いた記事では、RDF が「Mozilla の醜さ」の主な原因のようだ。


Mozilla 2 は、来るべき ECMAScrip Edition 4 ("JS2") をサポートした JIT 指向の JavaScript VM (詳細は近日) を備えているだろう (脚注 4) 。この VM に望ましいものの一つが、conservative でインクリメンタルな garbage collector (GC) だ。うまくいくようであれば、DOM オブジェクトのメモリ管理に、XPCOM のリファレンス・カウンティングではなく、この GC モジュールが使えるだろう。また、conservative なスキャニング・コードは、cycle collection を手助けできるだろう。さらに、JIT が直接 DOM glue code のエントリ・ポイントを呼び出すことができるだろう (JavaScript の mutation がメソッドのプロパティ値を上書きしていない、という前提だが)。そうなれば、 XPConnect の、パワフルではあるが相対的に遅い typelib ベースのディスパッチ機構を経由する必要がなくなる。


これによって、Firefox での Ajax のパフォーマンスは、一味も二味も違ったものになるだろう。




これはほんの手始めだ。


Mozilla 2 では API の互換性を遵守する必要がないので、より良い API を Gecko の「外部」に追加し、「内部」にある XPCOM API のボイラープレート (定型書式) を削除することができるし、するつもりだ。古くてベニヤ板のように薄っぺらい C++ portability は、移植性や性能や正確性で負担が増えない限り、標準的な C++ に翻訳できる。もしも、公平な比較でコードサイズとランタイム・パフォーマンスがすぐれているのなら、C++ 例外処理にスイッチ することさえできるだろう。


だから、次のようなコードは、


<pre>PRBool
nsXULDocument::OnDocumentParserError()
{
 // don't report errors that are from overlays
 if (mCurrentPrototype && mMasterPrototype != mCurrentPrototype) {
  nsCOMPtr<nsIURI> uri;
  nsresult rv = mCurrentPrototype->GetURI(getter_AddRefs(uri));
  if (NS_SUCCEEDED(rv)) {
   PRBool isChrome = IsChromeURI(uri);
   if (isChrome) {
    nsCOMPtr<nsIObserverService> os(
     do_GetService("@mozilla.org/observer-service;1"));
    if (os)
     os->NotifyObservers(uri, "xul-overlay-parsererror",
               EmptyString().get());
   }
  }
  return PR_FALSE;
 }
 return PR_TRUE;
}
</pre>

こんな風になるだろう。


<pre>bool
XULDocument::OnDocumentParserError()
{
 // don't report errors that are from overlays
 if (mCurrentPrototype && mMasterPrototype != mCurrentPrototype) {
  IURI *uri = mCurrentPrototype->GetURI();
  if (IsChromeURI(uri)) {
   GetObserverService()->NotifyObservers(uri, "xul-overlay-parsererror");
  }
  return false;
 }
 return true;
}
</pre>

(ここでの仮定として、Mozilla 2 の C++ バインディング・インターフェースから ns という接頭辞を削除でき、その代わりに正式な C++ の名前空間 [明示されていない] を使用できるものとしている。)


ここで、API の互換性を根拠もなく破棄するつもりはない、ということを付け加えておくべきだろう。みなさんのお陰で、API の中には問題のないものもある。Joel が書いたような意味での「大規模な書き直しではない」(全部を捨てて、初めからやり直す)。そして、実装コードの多くは、形を変える事はあっても保持されるだろう。


さて、これらのコードの変換を手作業で行なう、というのは望み薄だ。理由の一つとして、コードの多くは exception-safe ではない。そこで Oink の登場だ。Mozilla の手作業で書かれた allocate/free と lock/unlock のコードパターンの全てを RAII にコンバートするには、毎分 120 ワードでのタイピングを長時間できるイディオサバンの大群が必要だろう (脚注 5) 。しかし、Oink のフロントエンドである Elsa を使えば、ソースをリライトする作業を自動化できるのだ。そして、(Oink 側の flow-sensitive な作業があれば) exception-unsafe なケースをもれなく RAII にコンバートできたかをチェックすることもできるだろう。




Oink、と言うよりその友人の Cqual は、書き直すべきパターンを発見したり、例外の安全性を確認したりするよりも、より複雑なコード解析に向いている。適切な限定詞によって、次のような高度な safety properties を行なえる。例えば 、「ネットワーク由来の正規化されていない文字列の禁止」や「chrome (UI) コードは受け入れるコンテンツデータをサニタイズしなければならない」。


私が思うに、我々は Oink のフレームワークを拡張して、JS2 を含めたデータフローの解析ができるようにするべきだ。JS2 の type system があれば、より高いレベルのモデル・チェッカーを作るベースとなる、型の健全性を手に入れる事ができるだろう。


Oink を基にしたツールの作成は、一日でできるものではなく、もっとシンプルな方法でも充分な場合、深入りしないように注意するべきだ。しかし、私と Roc そして Graydon が見た限りでは、Oink はとても有望に思える。


だから、Mozilla 2 は、ただ単に、API を単純化し、古いコードと XPCOM の過負荷を除き、ソースコードをより親しみやすいものにするだけのものではない。プログラムのセキュリティに対する構成要素の改良でもある。これは、C や C++ といった言語によって実行される全てのブラウザにおいて、昔からの弱点だ。セキュリティは、抽象的な全てのレベルにおいての防衛を必要としている。上は JS の機密性プロパティの強化から、下はメモリ安全を確実にするべきバッファの操作まで。


銀の弾丸は存在しない (脚注 6) 。Michael Franz たちが指摘しているように、バーチャル・マシンは、TCB (trusted computing base) とトラック情報フローのサイズを減少し、より豊富なセキュリティのモデルとポリシーをサポートする、素晴らしい方法だ。安全な「ブラウザのマッシュアップ」。


我々は、Mozilla 2 のフレームワークで、JS2 VM を 積極的に最適化するだろう。しかし、近い将来に出る競争力があるブラウザで "managed C++" に移行する事はできない (Microsoft もできない事に注意)。また、JS2 も、どんなブラウザでもレンダリングと対話の基礎になる、ローレベルなシステム・プログラミングに適した言語ではない。


我々が取るのは、複合的なアプローチになるだろう。クリティカルなパスにはなく、安全なポインタだけを使用しているものを、できる限り "middleware" C++ から JS2 に移行する。ここでも、移行の自動化に Oink/Elsa が役立つだろう。私が夢想しているのは、C++ から JS2 に翻訳するコストを全てのコードで調べてスコア化し、作業が楽なものを静的に同定するようなチェッカーだ。一般的ユーザーレベルの作業とページ読み込みテストのプロファイリングの結果を使えば、C++ から JS2 に翻訳した方が良いように見えて、実はクリティカルなパスにあった、というようなものを除外するのに役立つだろう。


我々が、C++ から JS2 への変換を自動化するのに投資するか、それを手作業で行なうか、あるいは Oink を基にした手法と手作業との混合にするかは、ここでは決めたくない。しかし、COM による汚染を排除する作業と同じ様に、ツールを開発すれば作業をもっとスマートに行なえるだろう。プログラマの才能を、単調な繰り返しの多い大規模な作業で浪費せずに済む。


JS2 に移行できないような C++ も、Mozilla 2 の他の主要機能を使えば、もっとセキュアにできるだろう。conservative GC (フリーなメモリ読み込みの危険性を排除する)、Oink を基にしたチェッカー (我々のソースに註釈をつける、適切な新しい限定詞があれば)、そして、自動化されたテストを毎日 24時間で実行する valgrind プラス gcov の tinderbox などだ。


最後に、開発はできる限り低いセキュリティ権限でおこなわれ、権限を低くできない領域は、健全でドキュメントが豊富な OS のセキュリティ機構を使用する事になるだろう。開発プロセスの間、ほとんどのプラグインは除外されるべきだ。




私は、今後のグラフィック関連の作業 (3D canvas) やセキュリティ・モデル (安全なブラウザに基づいたマッシュアップ) についてまだ語っていない。また、Mozilla 2 をベースにするバージョンになると思われる Firefox 4 についてもほとんど語っていない。ただ、Mozilla 2 の開発の間も、ブランド名の付かない Firefox はビルドされ続ける、という事だけは言っておく。私の論点は、Firefox やそのアドオンやその他のアプリケーションが立脚・依存する Mozilla プラットフォームについてだ。


Mozilla 2 の目標をまとめると、


  • API の数を絞り、より良いものとし、「外部に置く」事によって、クリーンアップする。
  • Mozilla のコードベースを単純化して、より小さく、より高速に、そしてアプローチと維持を容易にする。
  • XPCOM と、その場しのぎのコードの代わりに、標準言語の機能と高速なパスを活用する。
  • JS2 に対する JIT コンパイルの使用などの最適化によって、DOM のアクセスを高速化し、メモリの使用量を減少する。
  • 重要なセーフティ・プロパティにおいてツールとランタイムを使用する。

そうそう。CVS を手放すにも良いタイミングなんじゃないか? 1.9 を混乱に陥れずに CVS を手放す一番いい方法は、CVS とマージできるような新しいバージョン・コントロール・システム (VCS) で Mozilla 2 を開発する事だ (まだ改修されていない、あるいは改修の必要がないファイルの変更を追っていく必要があるだろうし、バグを修正するためには 1.9 までさかのぼらなければならないようなものも見つかるだろう)。複数ある VCS の問題点は、現状で選択肢が多すぎる という事だ。それでも、リンクした表で緑色が多いものを見ていけば、決定にそう時間はかからないだろう。必要なのは「最良」や「最新」ではなく、マージとブランチとリネームのサポートがより良いものだ。


最後の論点。私がここで書いた事や、Mozilla における私の仕事のほとんどは、プラットフォームに焦点を当てている。しかし、我々は Firefox のようなアプリケーションを第一に考えており、万人のための「プラットフォーム」であると主張しているわけではない、というのは上記した通りだ。それでも、人々は XULRunner の上で動作する Songbird のようなアプリケーションを作っている。


とすれば、我々はどちらに進むべきか? プラットフォーム、あるいはアプリケーション? 回答は、「両方だ。好循環なら」。なぜなら、我々はユーザーを第一義的に扱ってきたが、いくつかの層で ―― ウェブ、XUL、C++ ―― 開発者も対象にしてきた。C++ の領域における我々の態度は、おざなりで探求も少ないものだった。長い目で見れば、C++ のコードベースを無視することはアプリケーションを危機にさらす。だから、Mozilla 2 では、この帳尻を合わせる予定だ。


もう充分だろう。詳細なロードマップと wiki での記述はこれからだ。私は、Mozilla のコードベースを、真の第二段階に進めたいのだ。クリーンで、無駄がなく、安全で、より良い API と C++ バインディングを持ち、そしてページの読み込みと DOM のパフォーマンスが高速な。言うは易く、行なうは難しだが、2008年には手の届くところにあるだろう。さあ、始めよう。





脚注、あるいは蛇足

1. リンク先文書の和訳は、「辞職そして追悼。」 Netscape 開発の初期メンバーでもあった Jamie Zawinski が mozilla.org を去るに当たって書いた文書。私見だが、この文書にもあるように、Zawinski はブラウザ+メーラーという Suite にこだわっていたのではないかと思われる。Zawinski が辞職していなければ Firefox は生まれなかったかも知れない。

2. 和訳:Mozilla 1.0 宣言。この文書の和訳の時にも、めちゃくちゃ苦労したような記憶がある。ちなみに、この文書の時点では Mozilla = 製品名だったが、Mozilla Suite の開発をコミュニティに任せた後からは、Mozilla = 開発コード名、あるいは Gecko を含むプラットフォームとしてのバックエンドの名前、と考えると良いだろう。

3. 「多数のコア CPU」の原語は "polycore CPU"。デュアルコアどころの騒ぎではなく、10 とか 20、あるいはそれ以上のオーダーを想定しているのかも知れない。なお、プレステ3 の GPU である RSX の浮動小数点演算性能 は 1.8 テラフロップ(らしい)。

4. Brendan Eich が XTech 2006 で行ったプレゼンテーション "JavaScript 2 and the Future of the Web" が公開されているので、合わせて参照されたい。Brendan が、4年後、すなわち 2010年を見据えている事がわかるだろう。スライドを進めるにはブラウザ画面を左クリック。白紙のスライドが出てもあわてないように。クリックすれば本文が出る。

5. 「イディオサバン」の原語は "OCD-savants"。"OCD" を「強迫神経症」の略と解釈し、"idiot savant" の意味であると取ったが、微妙に違うような気もする。イディオサバンについては「レインマン」とかを参照。(SF で出てきたのは「非A」だったと思うが、「虎よ、虎よ!」だったかも)

6. 狼男を一撃で退治する銀の弾丸のように、ソフトウェア開発時の問題を一挙に解決するような便利なものはない、という "No Silver Bullet" からの引用と思われる。




改版履歴
2006年10月26日: mal さんのアドバイスを基に校正。
2006年10月23日: 初稿

テーマ

関連テーマ 一覧


月別リンク

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(9件)

内 容 ニックネーム/日時
お疲れ様でした!level さんのところで簡単に書きましたが、
あんなに断定調では無いんですよね、助かります。
いくつか気になるところを。

「古い API とその移植」"old APIs and their implementations"
「古い API とその実装」でいいのでは。

「一味も二味も違ったものになるだろう」"kick ... up notch or three"
そうきましたか^^ 実際はどうなるのやら。JS 1.7 でも遅くなってるところがありましたし...

「XPCOM API のボイラープレートを削除」"remove XPCOM API boilerplate"
boilerplate は意味としては「定型文」「コード書法のパターン」というところなんでしょうが、うまい訳が思いつきません。
mal
2006/10/24 23:40
続きです。
「ベニヤ板のような古い C++ portability」"old C++ portability veneer"
veneer は「古い」にかかる形容詞ではないですよね。
「古い C++ portability の薄い層」「古い C++ の薄っぺらな portability」というのもおかしいですが…
portability は 「移植性」でしょうけれど、ここのところはちょっと難しいですね。

「ランタイム・パフォーマンス」"runtime performance"
このままでもいいですが、「実行時の性能」かなぁ。

「ネットワーク由来のフォーマット・ストリングの禁止」"no format string comes from the network"
「正規化されていない文字列の禁止」format=正規化 は問題ありですが、意味としてはこのようなものではないでしょうか。
mal
2006/10/24 23:42
これで終わりです。
「下はおそらくメモリが絡まないであろうバッファの操作まで」"down to buffer manipulations that should be provably memory-safe"
provably は probably の typo だとすれば、「下はおそらくメモリ安全にしたほうがよいバッファの操作まで」ではないでしょうか?

「開発はできる限り低いセキュリティ権限でおこなわれ」"we will run at reduced privilege when we can"
「(アプリケーション? Mozilla 2 環境?) の実行は...」ではないでしょうか?

Security 周りは自信が無いので、kozawa さんあたりのフォローがほしいところです^^;
mal
2006/10/24 23:43
ちょっと追記。
provably が prove の形容詞形なら 「下はメモリ安全を立証可能(確実)にするべきバッファの操作まで」ですかね。この方が当たりっぽいですが。
mal
2006/10/25 00:03
mal さん、コメントありがとうございます。
ご指摘の部分を見直して、改訂してみました。

> provably が prove の形容詞形
思いっ切り probably と読んでました(^^;
池田
2006/10/26 01:16
どうもです。私も provably は追記するまでそう思ってました^^

CVS ステは addons.m.o や mozilla.com が既に SVN に移行してるようなので徐々にというところじゃないですかね。
http://weblogs.mozillazine.org/preed/2006/08/subversive_subversion_conversi.html

RDF ステ発言も盛りあがってるようですが、
http://www.xulplanet.com/ndeakin/article/358?show=c
何年後かを考えると捨てるより作り直してほしいなぁ。
mal
2006/10/26 11:41
「多数のコア CPU」"polycore CPU" ですけど、Multi って言葉を使っていない点からも 池田さんも書かれているように Multi の先、PS3 の Cell や Intel が言う「メニィコア(Many-Core)CPU」の世代をイメージしているのかもしれませんね。。

Intel はコア数 100 のオーダにも言及してますが、そんなのが家庭のコンピュータに搭載されるなんて想像も出来ませんしw 並列性能を上げる為に Cell みたく異アーキテクチャコア混在タイプへ進むとしても CPUメーカ間の命令互換性はどうなるんだって不安も出てきますしね・・ (そこで差異を JIT VM で吸収するという発想だったりしてw)
tamcat
2006/11/06 01:11
>来るべき ECMAScrip Edition 4 ("JS2") をサポートした JIT 指向の JavaScript VM (詳細は近日)

まさかこういう展開になるとは想像もしていませんでした。

Adobe および Mozilla Foundation、オープンソースの Flash Player スクリプトエンジンを発表
http://www.mozilla-japan.org/press/releases/2006/11/07/
tamcat
2006/11/07 21:43
tamcat さん、コメントと情報提供ありがとうございます。
私も Adobe が出てくるとは「予想外」でした(^^;

たまさか時間があったので Frank Hecker のブログを和訳してみました。
http://firefoxhacks.at.webry.info/200611/article_2.html
お暇な折りにでもご一読いただければ。
池田
2006/11/09 00:10

コメントする help

ニックネーム
URL(任意)
本 文
Mozilla 2 和訳 Firefox Hacks 翻訳日記/BIGLOBEウェブリブログ
文字サイズ:       閉じる