Webアプリの進化に追随するGoogle Chrome：興味深い技術的側面（1/6 ページ）

Webアプリケーションの進化に追随するためにはブラウザ技術を向上させる必要があることをGoogleは認識した。Chromeのフードの下に隠された秘密にジェフ・コグスウェルが迫る。

[Jeff Cogswell，eWEEK]

　Googleの新しいブラウザChromeには、さまざまな新技術が盛り込まれている。今日のWebアプリケーションの進化に追随するためには、ブラウザ技術を向上させる必要があることをGoogleは認識したのだ。Chromeのフードの下に隠された秘密にジェフ・コグスウェルが迫る。

　ここではGoogleの新しいブラウザChromeを技術的見地から概観してみたい。ただし、基本構成の詳細を述べることはしない。また、クールな新機能について解説するつもりもない。これから書くことは、Chromeのドキュメンテーションを読んだり、ソースコードを調べたりしているときに、わたしが発見した幾つかの興味深い技術的側面に関することである。

　もしあなたがテクニカルオーバービューを求めているマネジャーなら、このままぜひ読み進んでもらいたい。また、もしあなたが開発者なら、Chrome開発に関する今後のわたしの記事の予備知識として、ざっと目を通していただければ幸いである。

マルチプロセッシングがついに！

　1日12時間以上もコンピュータの前で過ごす人々（わたしも含めて）は、毎朝ブラウザを立ち上げ、その日の仕事の進捗状況に応じて、次々と新しいタブをオープンしていく。いや冗談ではなく、わたしの場合、Firefoxで50以上のタブをオープンする日もある（それはそれで別の問題を提起しているかもしれないが、それはさておき）。タブを開けば開くほど、たとえいくつか閉じても、メモリはどんどん消費されていく。実際、ブラウザは300,000Kバイト以上を簡単に使い切る。1回のセッションでトップアウトすることも珍しくはない（そんなことは認めたくないが！）。

　さて、Chromeはメモリサイズ問題を完全に解決しているわけではないが、フラグメンテーションを少なくすることで対処している。従来のブラウザはシングルプロセスに割り当てられたワンセットの仮想メモリを利用する。それぞれのタブは、当然、そのセットの中のメモリブロックを占有する。ユーザーが新しいタブを開くと、メモリが次々に割り当てられる。ところがタブを閉じたとき、解放されたメモリが必ずしも将来のタブに対して十分な大きさであるとは限らないのだ。その結果、フラグメント化されたメモリの問題が浮上する（いま書いていることは、すべてGoogleの主張であることをはっきりさせておくべきだろう。わたしはFirefoxのソースコードを見ておらず、フラグメント化されたメモリが実際にどのようにハンドリングされるのか確認していない）。

　しかし、Chromeの場合、タブは自前のプロセスを実行する。そう、Chromeでは、ウィンドウではなく、タブがプロセスを持つのだ。わたしはこれまで20年ほど開発一筋でやってきたが、正直に言うと、単一のウィンドウに複数のプロセスをホストさせるなど考えたこともなかった。しかし、Chromeはまさにそうしている。

　実のところ、わたしはかなり疑り深い性分で、自分の目で確かめないかぎり何事も信じない。そこで、Process Explorer（Microsoft SysInternals製）を起動して、Chromeを実際に観察することにした。新しいタブを開いてProcess Explorerをチェックしてみる。なるほど、タブで新しいページをロードすると、新しいプロセスがスタートするではないか。もっとも、タブを開いただけでは、まだ新しいプロセスを割り当てない。タブにアドレスを入力し、実際のページがロードすると、chrome.exeの新しいインスタンスが立ち上がる。Process Explorerの助けを借りて、Chromeがchrome.exeの次のインスタンスを立ち上げるときのコマンドラインを確認した。インスタンスには、さまざまなコマンドラインパラメーターが含まれていた。例えば、--type=rendererは、明らかにそれがタブウィンドウであることをインスタンスに伝えるものだ。 また、一連の数値を従えた--channelは、おそらく親プロセスを特定し、通信するためのものだろう。

　これらのコマンドラインは、新しいタブにページをロードするたびに見ることができる。わたしはchrome.exeのインスタンスを幾つか走らせ、その状態であるページをロードしたタブのアドレスバーに新しいURLを入力した。すると、そのページに対応したchrome.exeインスタンスがクローズし、新しいインスタンスがスタートした。うむ、パーフェクトだ。chrome.exeは、閉じた既存ページに対応するメモリをクリーンアウトするのではなく、プロセス全体を完全にワイプアウトして新たにスタートする。Chromeはこの方法で、ページ相互の保護、隔離に加え、メモリのフラグメンテーションを阻止しているのだ。

　しかし、もっと興味深い点があった。www.yahoo.comをロードしたとき、わたしは奇妙なことに気づいた。2つのプロセスがスタートしたのだ。ところが、www.google.comのような小さなページでは1つのプロセスしか起動しない。それで2つ目のプロセスについては、おおよそ見当がついた。コマンドラインパラメーターを確認すると、予想通りだ。--typeコマンドラインパラメーターにプラグインがセットされていた。そして--plugin-pathというパラメーターが追加され、次のようにセットされていた。

c:\windows\system32\macromed\flash\npswf32.dll

　これはFlashプレーヤーだ。Chromeは、ページに埋め込まれたFlashプレーヤーに対しても、別のプロセスを起動するのだ。

　とにかく何でも（文字通り）壊さないと気がすまないエンジニアの1人として、わたしは考え得る限り最も簡単なテストを行うことにした。ChromeでYahoo!のページを開いたまま、プロセスをキルしてみたのだ。

　ビンゴ！　テストを実行に移すと、Yahoo!ページを表示していたタブの上部にメッセージが表示された。そしてFlashウィンドウ群（複数かって？　明らかに単一のプロセスがページ内のすべてのFlashプラグインをコントロールしていた）は、次のようなFlashロゴとサッドフェイスにリプレースされた。

図1　ChromeでクラッシュしたFlash

　Yahoo!のページは、それでも利用可能だった。言い換えれば、プラグインのクラッシュによってブラウザがクラッシュすることはなかった。同時に幾つもタブを開くユーザーには朗報といえるだろう。