Chromium Design Document学习及翻译之Multi-process Architecture
Chromium Design Document学习及翻译之Multi-process Architecture
http://www.chromium.org/developers/design-documents/multi-process-architecture

Multi-process Architecture

This document describes Chromium's high-level architecture.

Problem

It's nearly impossible to build a rendering engine that never crashesor hangs. It's also nearly impossible to build a rendering engine thatis perfectly secure.

In some ways, the current state of web browsers is like that of the single-user, co-operatively multi-tasked operating systems of the past. As a misbehaving application in such an operating system could take down the entire system, so can a misbehaving web page in a modern web browser. All it takes is one browser or plug-in bug to bring down the entire browser and all of the currently running tabs.

Modern operating systems are morerobust because they put applications into separate processes that arewalled off from one another. A crash in one application generally doesnot impair other applications or the integrity of the operating system, and each user's access to other users' data is restricted.

以上皆浮云，飘过

Architectural overview

We use separate processes for browser tabs to protect theoverall application from bugs and glitches in the rendering engine. We also restrict access from each rendering engine process to others and to the rest of the system. In some ways, this brings to web browsing the benefits that memory protection and access control brought to operating systems.

我们对browser的各个tabs分别分配各自的process，从而使得某个rendering engine（即对应下文的BRender）出现问题而导致整个浏览器应用程序崩溃。我们限制各个rendering engine process之间的下相互访问及访问浏览器中的其它系统。通过这些方法，使得浏览器能够获得由操作系统提供的内存安全及访问控制所带来的好处。

译注：这里的tabs管理，在启动chromium的时候，可以通过命令行参数来觉得如何管理所有的rendering engine，你是可以要求所有相关的domain内的页面都使用同一个rendering engine process。参看 --process-per-tab。参看下文的Sharing the render process
http://peter.sh/experiments/chromium-command-line-switches/中有所有chromium支持的启动参数。

We refer to the main process that runs the UI and manages tab and plugin processes as the "browser process" or "browser." Likewise, the tab-specific processes are called "render processes" or "renderers." The renderers use theWebKit open-source layout engine for interpreting and laying out HTML.

我们把运行UI，管理tab及plugin process的主process称为browser process或者browser. 同样各个tab的process我们称为render process或者renders。renders使用webkit作为layout engine来处理及解释HTML。

译注：一定注意browser和各个render之间都是通过相应的IPC机制间接通信的。
对这张图更详细的讲解，参看http://www.youtube.com/watch?v=A0Z0ybTCHKs
http://blog.marcchung.com/2008/09/05/chromes-process-model-explained.html， 着重解释了per-prcess-xxx的意思。
http://archrometects.files.wordpress.com/2009/10/assignment-01-conceptual-architecture-of-google-chrome-archrometects.pdf

Managing render processes

Each render process has a global RenderProcess object that manages communication with the parent browser process and maintains global state. The browser maintains a correspondingRenderProcessHost for each render process, which manages browser state andcommunication for the renderer. The browser and the rendererscommunicate usingChromium's IPC system.

管理render processes
每个render process都有一个全局的RenderProcess对象来管理它所对应的父browser process的交互及维护它的全局状态。父的browser process维护了对应于它所管理的render processes所需要的各个RenderProcessHost，用它来跟各个render通信。详细参看Chromium's IPC system.

Each render process has one or more RenderView objects, managed by theRenderProcess, which correspond to tabs of content. The correspondingRenderProcessHost maintains aRenderViewHost corresponding to each view in the renderer. Each view is given a viewID that is used to differentiate multiple views in the same renderer.These IDs are unique inside one renderer but not within the browser, soidentifying a view requires aRenderProcessHost and a view ID. Communication from the browser to a specific tab of content is done through theseRenderViewHost objects, which know how to send messages through theirRenderProcessHost to theRenderProcess and on to theRenderView.

管理Views
每个render process都有一个或多个RenderView对象，它们被对应着各个tab的内容的RenderProcess所管理。 每个RenderProcess在Browser进程都有其对应的RenderProceeHost,它又维护着与RenderView一一对应的RenderViewHost。同一个Render中的多个RenderView都有一个唯一的相互标识的View ID。在Browser进程中要想唯一的找到一个RenderView，需要view id和其对应的RenderProcessHost才行。Browser和各个Render之间的View的通信，需要经由RenderViewHost对象，从它找到对应的RenderProcessHost再到对应的RenderProcess最后确定想要通信的RenderView。

Components and interfaces

In the render process:

The RenderProcess handles IPC with the corresponding RenderProcessHost in the browser. There is exactly oneRenderProcess object per render process. This is how all browser ? renderer communication happens.
RenderProcess用来处理跟Browser侧的IPC交互，一个render process对对应唯一的一个RenderProcess。
The RenderView object communicates with its corresponding RenderViewHost in the browser process (via the RenderProcess), and our WebKit embedding layer. This object represents the contents of one web page in a tab or popup window
RenderView通过RenderProcess来与Browser Process中的RenderViewHost通信，同时也负责与Render内的Webkit layer的通信。一个Render Process可以有多个RenderView,它们分别对应一个tab内的一个或多个page或者popup window。

In the browser process:

• The Browser object represents a top-level browser window.
  Browser是最上层的browser应用程序的窗口
  
• The RenderProcessHost object represents the browser side of a single browser ? renderer IPC connection. There is oneRenderProcessHost in the browser process for each render process.
  RenderProcessHost对象表示了一个Browser与一个Render之间的IPC链接。 每个Rneder Process在Browser process中都有对应的一个RenderProcessHost
  
• The RenderViewHost object encapsulates communication with the remoteRenderView, andRenderWidgetHost handles the input and painting forRenderWidget in the browser.
  RenderViewHost对象啊帛喊了与render中的RenderView之间的通信，而RenderWidgetHost控制了Browser process与Render中的RenderWidget的输入与描画。
  译注：关于RenderWidget，在上图中并没有画出来，它其实是一个RenderView的基类，相关信息参照How Chromium displays web pages 中的详细描述。
  For more detailed information on how this embedding works, see the How Chromium displays web pages design document.
  Sharing the render process

  In general, each new window or tab opens in a new process. The browserwill spawn a new process and instruct it to create a singleRenderView.

  Sometimes it is necessary or desirable to share the render process betweentabs or windows. A web application opens a new windowthat it expects to communicate with synchronously, for example, using window.open in JavaScript. In this case, when we create a new window or tab, we needto reuse the process that the window was opened with. We also have strategies to assign new tabs to existing processes if the total number of processes is too large, or if the user already has a process open navigated to that domain. These strategies are described in Process Models.
  
  共享render process
  通常，每个新的window或者tab都会在一个新的process中打开。browser会复制一个新的process来，并且告诉它如何创建一个RenderView.
  有时，也会有需要在多个tabs或者windows间共享一个render process。一个web应用程序打开了个新的windows，并希望它能够与原来的windows之间同步的通信，例如，在javascript中使用window.open来打开一个新的window。这种情况下，我们创建的心的window或者tab，就会需要使它们共享同一个render process。同时，chromium也提供一个策略，如果已有的process已经太多了，那么新开的tabs就会与某个已经存在的process共享一个render process，或者如果用户已经在浏览同一个domain的tab，再开同一个tab就会与该tab共享render process。详细请参看Process Models.
  

  
  

  Each render process has one or more RenderView objects, managed by theRenderProcess, which correspond to tabs of content. The correspondingRenderProcessHost maintains aRenderViewHost corresponding to each view in the renderer. Each view is given a viewID that is used to differentiate multiple views in the same renderer.These IDs are unique inside one renderer but not within the browser, soidentifying a view requires aRenderProcessHost and a view ID. Communication from the browser to a specific tab of content is done through theseRenderViewHost objects, which know how to send messages through theirRenderProcessHost to theRenderProcess and on to theRenderView.

  
  

  管理Views
  每个render process都有一个或多个RenderView对象，它们被对应着各个tab的内容的RenderProcess所管理。 每个RenderProcess在Browser进程都有其对应的RenderProceeHost,它又维护着与RenderView一一对应的RenderViewHost。同一个Render中的多个RenderView都有一个唯一的相互标识的View ID。在Browser进程中要想唯一的找到一个RenderView，需要view id和其对应的RenderProcessHost才行。Browser和各个Render之间的View的通信，需要经由RenderViewHost对象，从它找到对应的RenderProcessHost再到对应的RenderProcess最后确定想要通信的RenderView。

  
  

  Components and interfaces

  In the render process:

  The RenderProcess handles IPC with the corresponding RenderProcessHost in the browser. There is exactly oneRenderProcess object per render process. This is how all browser ? renderer communication happens.
  RenderProcess用来处理跟Browser侧的IPC交互，一个render process对对应唯一的一个RenderProcess。
  The RenderView object communicates with its corresponding RenderViewHost in the browser process (via the RenderProcess), and our WebKit embedding layer. This object represents the contents of one web page in a tab or popup window
  RenderView通过RenderProcess来与Browser Process中的RenderViewHost通信，同时也负责与Render内的Webkit layer的通信。一个Render Process可以有多个RenderView,它们分别对应一个tab内的一个或多个page或者popup window。
  

  
  

  In the browser process:

  • The Browser object represents a top-level browser window.
    Browser是最上层的browser应用程序的窗口
    
  • The RenderProcessHost object represents the browser side of a single browser ? renderer IPC connection. There is oneRenderProcessHost in the browser process for each render process.
    RenderProcessHost对象表示了一个Browser与一个Render之间的IPC链接。 每个Rneder Process在Browser process中都有对应的一个RenderProcessHost
    
  • The RenderViewHost object encapsulates communication with the remoteRenderView, andRenderWidgetHost handles the input and painting forRenderWidget in the browser.
    RenderViewHost对象啊帛喊了与render中的RenderView之间的通信，而RenderWidgetHost控制了Browser process与Render中的RenderWidget的输入与描画。
    译注：关于RenderWidget，在上图中并没有画出来，它其实是一个RenderView的基类，相关信息参照How Chromium displays web pages 中的详细描述。
    For more detailed information on how this embedding works, see the How Chromium displays web pages design document.
    Sharing the render process

    In general, each new window or tab opens in a new process. The browserwill spawn a new process and instruct it to create a singleRenderView.

    Sometimes it is necessary or desirable to share the render process betweentabs or windows. A web application opens a new windowthat it expects to communicate with synchronously, for example, using window.open in JavaScript. In this case, when we create a new window or tab, we needto reuse the process that the window was opened with. We also have strategies to assign new tabs to existing processes if the total number of processes is too large, or if the user already has a process open navigated to that domain. These strategies are described in Process Models.
    
    共享render process
    通常，每个新的window或者tab都会在一个新的process中打开。browser会复制一个新的process来，并且告诉它如何创建一个RenderView.
    有时，也会有需要在多个tabs或者windows间共享一个render process。一个web应用程序打开了个新的windows，并希望它能够与原来的windows之间同步的通信，例如，在javascript中使用window.open来打开一个新的window。这种情况下，我们创建的心的window或者tab，就会需要使它们共享同一个render process。同时，chromium也提供一个策略，如果已有的process已经太多了，那么新开的tabs就会与某个已经存在的process共享一个render process，或者如果用户已经在浏览同一个domain的tab，再开同一个tab就会与该tab共享render process。详细请参看Process Models.

    
    

    Detecting crashed or misbehaving renderers

    Each IPC connection to a browser process watches the process handles.If these handles are signaled, the render process has crashed and thetabs are notified of the crash. For now, we show a "sad tab" screen that notifies the user that the renderer has crashed. The page can be reloaded by pressing the reload button or by starting a new navigation. When this happens, we notice that there is no process and create a new one.

    
    

    单个tab crash只会影响该tab的render process，不会影响其它tab，可以单独重新加载出问题的该tab。

    
    

    Sandboxing the renderer

    Given Webkit is running in a separate process, we have the opportunity to restrict itsaccess to system resources. For example, we can ensure that the renderer's only access to the network is via its parent browser process. Likewise, we can restrictits access to the filesystem using the host operating system's built-in permissions.

    In addition to restricting the renderer's access to the filesystem and network, we canalso place limitations on its access to the user's display and related objects. We run each render process on a separate Windows "Desktop" which is not visible to the user. This prevents a compromised renderer from opening new windows or capturing keystrokes.

    
    

    每个webkit都工作在独立的一个process中，我们就可以限制各个webkit对系统资源的访问。例如，我们可以确保一个render只会通过它的父browser进程来访问网络。同样的，我们可以通过宿主操作系统内建的filesytem权限来控制该webkit对文件系统的访问。
    更进一步，我们还能限制render访问用户的display和相关的对象。这样就防止了一个受攻击的render能够去影响或窃取其它render的信息。

    
    

    Giving back memory

    Given renderers running in separate processes, it becomes straightforward to treat hidden tabs as lower priority. Normally, minimized processes on Windows have their memory automatically put into a pool of "available memory." In low-memory situations, Windows will swap this memory to disk before it swaps out higher-priority memory, helping to keep the user-visible programs more responsive. We can apply this same principle to hidden tabs. When a render process has no top-level tabs, we can release that process's "working set" size as a hint to the system to swap that memory out to disk first if necessary. Because we found that reducing the working set size also reduces tab switching performance when the user is switching between two tabs, we release this memory gradually. This means that if the user switches back to a recently used tab, that tab's memory is more likely to be paged in than less recently used tabs. Users with enough memory to run all their programs will not notice this process at all: Windows will only actually reclaim such data if it needs it, so there is no performance hit when there is ample memory.

    This helps us get a more optimal memory footprint in low-memory situations. The memory associated with seldom-used background tabs can get entirely swapped out while foreground tabs' data can be entirely loaded into memory. In contrast, a single-process browser will have all tabs' data randomly distributed in its memory, and it is impossible to separate the used and unused data so cleanly, wasting both memory and performance.

    
    让每个render工作在独立的process中，使得可以降低隐藏着的tab的优先级。类似与windows对于一些进程的活动内存的分配，可以使得那些用户能看到的进程有更多的活跃的内存被使用。 当一个tab没有被激活或者被用户操作，可以降低它对与内存的需求阀值，就可以使得在必要的时候，系统可以把它所有的一部分内存给释放掉，以供其它更紧急的应用使用。当然，这样做会降低tab之间切换的效率，所以，对于这些内存的释放都是逐步的。
    
    译注：这里就像是一个kernel中的cache管理，有冷/热之分，但是kernel中已经不在使用cold/hot的两个list来管理page了，不知道chromium之后会不会也会有所改变。这都是跟应用场景相关的决策，不可能有完美的解决方案，只会有适合最常用情况下的最好方案

    Plug-ins Firefox-style NPAPI plug-ins run in their own process, separate from renderers. This is described in detail inPlugin Architecture.

    
    

    Resources

    
    

    Multi-threaded user interface in Windows on MSDN.

    
    

    Detecting crashed or misbehaving renderers

    Each IPC connection to a browser process watches the process handles.If these handles are signaled, the render process has crashed and thetabs are notified of the crash. For now, we show a "sad tab" screen that notifies the user that the renderer has crashed. The page can be reloaded by pressing the reload button or by starting a new navigation. When this happens, we notice that there is no process and create a new one.

    
    

    单个tab crash只会影响该tab的render process，不会影响其它tab，可以单独重新加载出问题的该tab。

    
    

    Sandboxing the renderer

    Given Webkit is running in a separate process, we have the opportunity to restrict itsaccess to system resources. For example, we can ensure that the renderer's only access to the network is via its parent browser process. Likewise, we can restrictits access to the filesystem using the host operating system's built-in permissions.

    In addition to restricting the renderer's access to the filesystem and network, we canalso place limitations on its access to the user's display and related objects. We run each render process on a separate Windows "Desktop" which is not visible to the user. This prevents a compromised renderer from opening new windows or capturing keystrokes.

    
    

    每个webkit都工作在独立的一个process中，我们就可以限制各个webkit对系统资源的访问。例如，我们可以确保一个render只会通过它的父browser进程来访问网络。同样的，我们可以通过宿主操作系统内建的filesytem权限来控制该webkit对文件系统的访问。
    更进一步，我们还能限制render访问用户的display和相关的对象。这样就防止了一个受攻击的render能够去影响或窃取其它render的信息。

    
    

    Giving back memory

    Given renderers running in separate processes, it becomes straightforward to treat hidden tabs as lower priority. Normally, minimized processes on Windows have their memory automatically put into a pool of "available memory." In low-memory situations, Windows will swap this memory to disk before it swaps out higher-priority memory, helping to keep the user-visible programs more responsive. We can apply this same principle to hidden tabs. When a render process has no top-level tabs, we can release that process's "working set" size as a hint to the system to swap that memory out to disk first if necessary. Because we found that reducing the working set size also reduces tab switching performance when the user is switching between two tabs, we release this memory gradually. This means that if the user switches back to a recently used tab, that tab's memory is more likely to be paged in than less recently used tabs. Users with enough memory to run all their programs will not notice this process at all: Windows will only actually reclaim such data if it needs it, so there is no performance hit when there is ample memory.

    This helps us get a more optimal memory footprint in low-memory situations. The memory associated with seldom-used background tabs can get entirely swapped out while foreground tabs' data can be entirely loaded into memory. In contrast, a single-process browser will have all tabs' data randomly distributed in its memory, and it is impossible to separate the used and unused data so cleanly, wasting both memory and performance.

    
    让每个render工作在独立的process中，使得可以降低隐藏着的tab的优先级。类似与windows对于一些进程的活动内存的分配，可以使得那些用户能看到的进程有更多的活跃的内存被使用。 当一个tab没有被激活或者被用户操作，可以降低它对与内存的需求阀值，就可以使得在必要的时候，系统可以把它所有的一部分内存给释放掉，以供其它更紧急的应用使用。当然，这样做会降低tab之间切换的效率，所以，对于这些内存的释放都是逐步的。
    
    译注：这里就像是一个kernel中的cache管理，有冷/热之分，但是kernel中已经不在管理cool/hot的memory page了，不知道chromium之后会不会也会有所改变。这都是更应用场景相关的决策，不可能有完美的解决方案，只会有适合最常用情况下的最好方案

    Plug-ins Firefox-style NPAPI plug-ins run in their own process, separate from renderers. This is described in detail inPlugin Architecture.

    
    

    Resources

    
    

    Multi-threaded user interface in Windows on MSDN.