ChromeはGoogleからリリースされ、とにかく動作が速いということで注目を集めた。高速なのは興味深いことだが、ほかのブラウザでも積極的に改善が進められているためブラウザ事情に精通したデベロッパはさほど驚かなかっただろう。デベロッパとしてはむしろ、単一のプロセスではなく複数のプロセスを生成して動作するという点に興味を持ったのではないだろうか。Chromeには既存のオープンソースプロジェクトの成果物が活用されているため、実装の新規性よりも組み合わせや改善のうまさが際立つ。新アイディアという点で見ると、Chromeで注目すべきはマルチプロセスアーキテクチャという設計にある。Architectureにわかりやすい説明がまとまっている。Chrome以外の主要ブラウザは単一のプロセスで動作するが、Chromeは多くのシステムプロセスを生成する。1ブラウザ1プロセスは歴史的な背景やリソースを抑えるという点で無難な設計だが、Webアプリを日常的に使うようになった昨今では1つのバグが動作しているすべてのブラウザウィンドウやタブを引き連れてクラッシュしてしまうという問題も抱えている。クラッシュ時に開いていたウィンドウやタブを復旧する機能が実装されるなど対応も進められているが根本的な解決ではない。Chromeの本体となるブラウザプロセス、レンダリングを担当するレンダリングエンジンプロセス、プラグインと通信するプラグインプロセスという3種類のシステムプロセスを生成してレンダリングエンジンがバグでクラッシュしてもほかのブラウジングには影響がでない仕組みを考案した。これがマルチプロセスアーキテクチャだ。ブラウザプロセスはウィンドウ本体のプロセス。ディスクアクセス、ネットワークアクセス、ユーザ入力、画面出力を統括する。レンダリングエンジンプロセスはレンダリングエンジンをプロセスとして分離するもので、マルチプロセスアーキテクチャのアイディアの要だ。レンダリングエンジンがクラッシュしてもシステムプロセスとして分離しているためほかのレンダリングには影響を与えない。同じサイトの場合は新しくウィンドウやタブを開いても同じレンダリングプロセスが使われる。サイトごとに新しくレンダリングプロセスが生成される仕組みだ。プラグインプロセスはプラグインを別プロセスとして分離するものだ。レンダリングは複雑な処理であり問題を完全に排除することは難しい。あればシステムプロセスとして分離してクラッシュしてもほかの処理に問題がでないようにするというのは妥当な戦略だ。開くサイトが増えるごとにレンダリングプロセスが生成されていくということは、それだけOSの動作が重くなることを意味している。スレッドよりもプロセスの方がコンテキストスイッチの負荷が大きいからだ。このためChromeではデフォルトでレンダリングプロセスの生成数上限を20に設定し、それ以降のレンダリングプロセス要求に対してはすでに動作しているレンダリングプロセスを使いまわすように設定している。通常の使い方をしている限り、この設定は妥当なものだと説明されている。マルチプロセスアーキテクチャとそのアルゴリズムは現在は単純なもので、今後はさらにプロセスの生成やスワップ処理について改善が加えられるという。※本記事は掲載時点の情報であり、最新のものとは異なる場合があります。Corporation。