Webkitプロジェクトにおいて、Appleの開発者Anders Carlssonより"分割プロセスモデル(split process model)"を採用したWebKit2がアナウンスされました。

[webkit-dev] Announcing WebKit2 コメントを見る
This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework "WebKit2".
WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it.

Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2

かいつまんで説明すると、コンテンツ部分(JavaScript, HTML, layout, etc)とアプリケーションのUIを分離したモデルとなります。マルチプロセスは既にGoogle Chromeが実現していますが、どのアプリケーションからも利用できるフレームワークであることが大きな違いとされます。

ブラウザに於いて、クラッシュの原因のほとんどはプラグイン(主にAdobe Flash)にあり、プロセスの分離作業が進められています。
MacOS X 10.6(Snow Leopard)においてはSafariとプラグイン動作が別プロセスに、Firefoxは"Lorentz"プロジェクトでプラグインの実行プロセスの分離に取り組んでいます。

APIの互換性がないため、現在のアプリケーションでは動作しませんが、近い将来(in the near future.)動かすことが出来る見込みです。


WebKit2 -- WebKit コメントを見る

WebKit2 - High Level Document

WebKit2 is a new API layer for WebKit designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it.

WebKit2 - 上級文書

WebKit2は、ウェブのコンテンツ(JavaScript,HTML,レイアウト等)をアプリケーションUIから別のプロセスに分離する為の新しいAPI層です。Google Chromeが提供しているものに極めてよく似ていますが、直接フレームワークにプロセス分割モデルを構築して、他のWebKitクライアントが利用できることが大きく異なります。

Why is it named WebKit2?

The somewhat pedestrian reason is that it's an incompatible API change from the original WebKit, so it will probably be installed as something like /System/Library/WebKit2.framework on Mac.


つまらない理由ですが、オリジナルのWebKitのAPIと非互換なためです。Macではおそらく/System/Library/WebKit2.framework と言った具合にインストールされるでしょう。


WebKit2 will provide a stable C-based non-blocking API that is mostly platform agnostic. In order to achieve the goal of a non-blocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. These techniques include:
  • Notification style client callbacks (e.g. didFinishLoadForFrame) These inform the embedder that something has happened, but do not give them the chance to do anything about it.
  • Policy style clients callbacks (e.g. decidePolicyForNavigationAction) These allow the embedder to decide on an action at their leisure, notifying the page through a listener object.
  • Policy settings (e.g. WKContextSetCacheModel, WKContextSetPopupPolicy) These allow the embedder to opt into a predefined policy without any callbacks into the UIProcess. These can either be an enumerated set of specific policies, or something more fine-grained, such as a list of strings with wildcards.
  • Injected code (e.g. WebBundle) Code can be loaded into the WebProcess for cases where all the other options fail. This can useful when access to the DOM is required. [Planned, but not currently implemented]
The major API classes are:

  • Encapsulates all pages related to specific use of WebKit. All pages in this context share the same visited link set, local storage set, and preferences.
  • WKPageNamespaceRef

Encapsulates all pages that can script each other.
  • WKPageRef
Basic unit of browsing. Stays the same as the main frame changes.
  • WKView[Ref]

Native view that hooks into the platform's toolkit. On Windows, this wraps a HWND. On the Mac, it inherits from NSView.
Note that the requirement to be fully non-blocking requires an incompatible API break - many features of most existing WebKit APIs cannot be fulfilled in a non-blocking manner. Since we needed the API break anyway, we also took advantage of the opportunity to clean up and simplify the API.

Port-Specific APIs

We plan to build a fully non-blocking Objective-C API for Mac OS X as a wrapper on top of the C API. We believe a similar approach may be viable for other ports.

We are also not removing or obsoleting any of the existing port-specific APIs. WebCore will remain as-is, and all current APIs will continue to work and be fully supported. Thus, WebKit development and existing ports of WebKit will not be disrupted.

移植志向 API

Mac OS X向けにC APIの上にラッパーした完全なノンブロックObjective-C APIを計画しています。同様のアプローチは、他の移植でも可能と確信しています。

Process Architecture

WebKit2 changes the WebKit stack to build a process management mechanism inside the WebKit API layer.
Here is what the architecture of a traditional WebKit port looks like:
WebKit2ではWebKit API層内部のプロセス管理機構を構築するためのスタックを変更しています。 伝統的なWebKitのアーキテクチャはこんな風に
Everything is in one process, and there is an API boundary between the application and the WebKit API. This is a simple model, and typically it's pretty easy for applications to reuse the WebKit API.

Here is what we are going for with WebKit2:
全ては1つのプロセスで、API境界はアプリケーションとWebKit APIの間にあります。シンプルなモデルで、一般的にアプリケーションがWebKit APIを再利用するのは非常に簡単です。
Notice that there is now a process boundary, and it sits *below* the API boundary. Part of WebKit operates in the UI process, where the application logic also lives. The rest of WebKit, along with WebCore and the JS engine, lives in the web process. The web process is isolated from the UI process. This can deliver benefits in responsiveness, robustness, security (through the potential to sandbox the web process) and better use of multicore CPUs. There is a straightforward API that takes care of all the process management details for you.
APIの境界の下にあるプロセスの境界に注意してもらいたい。UIプロセスのWebKitオペレータはアプリケーションロジックと共に動作します。WebCoreやJS engineを含む残りのWebKitはWebプロセスと共に動作します。WebプロセスはUIプロセスから独立します。これによって、応答性、堅牢性、安全性(Webプロセスをサンドボックス化する)と、マルチコアCPUの効率的な利用というメリットがあります。細やかなプロセス管理を可能とするAPIがあります。

How is This Different from Chromium WebKit?

Chromium takes a different approach to multiprocess:
Notice that in this case, the the process boundary is *above* the API boundary. Chromium WebKit does not directly provide a multiprocess framework, rather, it is optimized for use as a component of a multiprocess application, which does all the proxying and process management itself. The Chrome team at Google did a great job at trailblazing multiprocess browsing with Chrome. But it's difficult to reuse their work, because the critical logic for process management, proxying between processes and sandboxing is all part of the Chrome application, rather than part of the API layer. So if another WebKit-based application or another port wanted to do multiprocess based on Chromium WebKit, it would be necessary to reinvent or cut & paste a great deal of code.

That was an understandable choice for Google - Chrome was developed as a secret project for many years, and is deeply invested in this approach. Also, there are not any other significant API clients. There is Google Chrome, and then there is the closely related Chrome Frame.

WebKit2 has a different goal - we want process management to be part of what is provided by WebKit itself, so that it is easy for any application to use. We would like chat clients, mail clients, twitter clients, and all the creative applications that people build with WebKit to be able to take advantage of this technology. We believe this is fundamentally part of what a web content engine should provide.

Chromium WebKitとどう異なるか


プロセス境界がAPI境界の上にあることに注意して下さい。ChromiumのWebKitでは直接利用できるマルチプロセスフレームワークを提供しておらず、替わりに自身で利用するプロセス管理を利用するよう最適化されています。GoogleのChromeチームは、先駆的なマルチプロセスブラウジングで素晴らしい仕事をしました。しかし,プロセスとサンドボックス間はAPI層の替わりにChromeアプリケーションの重要なロジックで実装されている為、彼らの業績を再利用するのは困難です。他のWebKitベースのアプリケーションはマルチプロセスをChronium WebKitベースで実現しようとした場合には、大幅に改訂するか大量のコードをカット&ペーストする必要があります。

Googleの選択は理解できます - Chromeは何年もの間秘密プロジェクトとして、ひっそりと開発されました。また、興味深いAPIクライアントはありません。Google Chromeであり、Chrome Frameと密接に関連するのです。

WebKit2は異なる目標を持っています - 私たちは、WebKitが利用するアプリケーションが簡単に利用できるWebKit自体によって提供されるプロセス管理を欲しています。 WebKitを利用して作られるチャットクライアント、メールクライアント、Twitterクライアント、クリエイティブアプリケーション全てが標準的に利用できる技術にしたいのです。Webコンテンツエンジンが提供する基礎的な要素と信じます。


There are two key subsystems that support the process division :
  • CoreIPC - an abstraction for general message passing, including event handling. The current implementations use mach messages on Mac OS X, and named pipes on Windows.
  • DrawingArea - an abstraction for a cross-process drawing area. Multiple drawing strategies are possible, the simplest is just a shared memory bitmap.
There are two other important abstractions, which may be pushed down to WebCore or WTF over time:
  • Run Loops
  • Work Queues

Current Status

WebKit2 should be considered an early technology demo. It is not yet production quality. But it's possible to try it out and see how it works at this early stage.



How to try it Out

Use build-webkit --webkit2 on Mac OS X or Windows to build everything. WebKit2 will not work with the shipping version of Safari. Because WebKit2 is an incompatible API break, it requires a custom testbed to run it. A basic web browser application suitable for testing WebKit2 will be landed in the near future.