chromiumのプロセスモデル

Overview

Webのコンテンツは膨大な動的コードを含むようになって、よりドキュメントというよりはアプリケーションになってきている。この変化によって、
ブラウザは単なるドキュメントのレンダラではなく、OSの役割を果たすようになってきた。chromniumはOSがやっているように、サイトやブラウザを複数のOSのプロセスを使って隔離しています。ウェブアプリケーションを安全で堅牢に実行するためOSのように作られています。
その結果、アドレス空間が別になり、OSによってスケジュールされるようになるので、ひとつに問題が出てもほかに影響しません。ユーザはchromiumのTask Managerで各プロセスのリソース使用量をチェックできます。

Supported models

ブラウザをOSのプロセスにどう分割するかを決めるモデルを4つサポートしている。
各モデルは、コンテンツのoriginに応じてどうプロセスを分割するかが異なる。

Process-per-site-instance

デフォルト。
サイトごとに違うレンダリングプロセスを作る。新しく同じサイトを開いたら別のプロセスを割り当てる。
ひとつのサイトとして認識する範囲はSame Origin Policyの範囲。ただしTLDが同じなら同じものとみなす。これはjsでdocument.domainを変更して互いにアクセスできるようにするため。

Strengths

異なるサイトのコンテンツを分離できる
同じサイトでもタブが違えば分離できる(同じサイトの片方が落ちても片方は生き残る)

Weaknesses

メモリオーバーヘッドが大きい レンダリングプロセスがたくさん生成される
windowを経由したりする一部のjs呼び出しにIPCが必要

Process-per-site

同じサイトは全部ひとつのプロセスで実行する。 –process-per-site

Strengths

異なるサイトのコンテンツを分離できる
Process-per-site-instanceと比べてメモリが節約できる

Weaknesses

ひとつのレンダリングプロセスが肥大化する google.comを扱うプロセスなど。ページのどれかが落ちたりリソースの競合が起きて全滅したときに困る。
windowを経由したりする一部のjs呼び出しにIPCが必要

Process-per-tab

process-per-site-instanceやprocess-per-siteがコンテンツのoriginを考慮するのと比較してシンプルなモデル。 –process-per-tab
ひとつのタブとそれこからスクリプトで開かれたタブをHTML5の”unit of related browsing contexts”として扱い、ひとつのレンダリングプロセスで処理する。
シリアライズなしでjavascriptを呼び出すことができる(訳注: スクリプトで開かれたページ同士はスクリプトを相互に参照することが多いことを想定してのモデルなのだろう)。

Strengths

理解しやすい。タブに割り当てられたプロセスはずっと変わらない。

Weaknesses

複数のページが望まない運命をともにすることになる。違うドメインのページを開いても同じプロセスに属する。

Single process

評価目的。 –single-process
FirefoxとかSafariの採用しているモデル。
multi-process architecturesで生じるオーバーヘッドの測定用。安全でないし脆弱。どれかのレンダラがクラッシュしたら全部落ちる。
テスト/開発用でほかのモデルにはないバグがある。

Sandboxes and plug-ins

各レンダリングエンジンはユーザのコンピュータへのアクセスが制限されたsandboxed process の中で実行される。
各レンダリングエンジンはファイルシステム、ディスプレイ、その他大半のリソースに直接アクセスできない。
セキュリティポリシーの適用を行うブラウザプロセス経由でアクセス権限を得ることができる。
結果としてレンダリングエンジンが悪用されても影響を小さくできる。

例外的に、Flashなどのプラグインはプラグインごとに、sandboxではないひとつのプロセスが作られる。つまり、それがどのタブに表示されるかにかかわらずflashは全部ひとつのプロセスで実行される。

Caveats

ベータリリースでは multi-process architectures の全部は実装されていない。
現在の実装の注意点と their implications.

• リンクのクリック、フォームの送信がcross-siteでも、レンダラはじまりのナビゲーションではいまのところプロセスはスイッチしない。
  今はブラウザのlocation barやブックマークからcross-siteなのを呼び出したときだけスイッチする。
  process-per-site-instance, process-per-siteでもこういう動作(訳注: つまり現状Process-per-tabモデルに近い)。

  将来的に変わる予定。

  例外的にスクリプトでabout:blankを開いてからページをリダイレクトさせたときには新しくレンダリングプロセスが作られる。gmailが使っている手法。同じようにすればほかのサイトでも同じ動作をする。

• frameもおなじレンダリングプロセスで実行される。でもcross-siteフレームはparentにアクセスできないので安全に実行できる。
  将来的に変わる予定。

• 全体のプロセス数に制限がある。オニのようにプロセスを作らないようにするため。
  いまのところ大体のマシンではレンダリングプロセスを20までしかつくれない。搭載メモリ量によってはこれより少ない。
  結果としてひとつのレンダリングプロセスが複数のサイトに割り当てられることがある。割り当てられ方はランダム。
  将来的にはもっと賢いヒューリスティックな選び方になる予定。

ロケーションバーで検索したときは browser-initiated navigation だけどプロセスをスイッチしない。ひとつめのcaveatが原因。
頻繁に検索するprocess-per-site modelのユーザだと、大半のページがひとつのレンダリングプロセスで実行されることになる。

したがって、ロケーションバーの検索結果は、サーチエンジン専用のプロセスではなくて開いていたタブのプロセスで実行される。
結果としてひとつのサイトに複数のプロセスが割り当てられることがある。

次のバージョンではヒューリスティックを使うけど、ひとつめのcaveatが解決したら取り除く予定。

Implementation notes

さまざまなプロセスモデルをBrowsingInstanceとSiteInstanceというクラスで表現している。
BrowsingInstance はHTML5のbrowsing contextsと結び付けられたもの。
process-per-tab modelのときはBrowsingInstanceごとにレンダリングプロセスが作られる。

SiteInstance は同じサイトのページの集合を表す。BrowsingInstanceの中のページをさらに分割したもの。
重要な点として、ひとつのBrowsingInstance内ではひとつのサイトごとにひとつだけしかSiteInstanceが存在しない。
process-per-site-instance modelでは各SiteInstanceごとにレンダリングプロセスが作られる。