Conceptual Architecture Analysis: Google Chrome

Bote Jiang, Zheng Peng, Shihao Lu, Zhizi Jiang, Tianbo Ma. Zongmin YuThe Team to Success

CISC 326 (Oct. 19th 2018)Queen’s School of Computing

Abstract

In this analysis, we look at Chromium/Chrome’s conceptual architecture. Through synthesizing the reference architecture of modern web browsers, we proposed that Chromium/Chrome is a layered style combined with some object-oriented aspects in the lower level subcomponents.

There are three main layers in our proposed conceptual architecture: UI, Browser, and Renderer layers. The UI layer is responsible for displaying the graphics to the user, the browser engine is responsible for managing the communication and connection between the renderer and the UI, and the renderer or the render process is responsible for taking web data and turning it into a visual representation of the webpage.

There are several recurring themes and properties throughout the entire architecture: 1. Multiprocessing and 2. Stability, security, and integrity. Both properties are interconnected as allowing for multiprocessing requires an emphasis on security and integrity, and vice versa.

We conclude that Chromium/Chrome’s architecture is similar to the reference architecture but with some important changes. One of which is the grouping of multiple lower level components into the renderer and another is the ability to create multiple renderers.

Introduction

Google Chrome is a cross-platform freeware released 10 years ago. In 2018, Chrome is by far the most popular web browser with a multiple platform combined market share of 51%. [1] Originally designed to take on the works of established browsers like Mozilla Firefox and Microsoft’s Internet Explorer, Chrome was designed with the balance of minimalism and performance in mind. It was the first to introduce a number of now ubiquitous features such as bookmark synchronization, multiple web-standard support, combined search and URL bar, just to name a few. [2] As of September 2018, the last stable release is version 69 and it is also consistently pushing out new betas and developer channel updates.

For source code sharing, Google launched alongside its main product, Chromium, an open-source version of Chrome. [3] The Chromium Project is led by Google developers and is kept up to date by community developers. Though Chrome and Chromium are fundamentally the same as they share the same performance and visual design philosophies. There are only a few differences. Key differences include: Chrome being packaged into an installer while Chromium is not, slightly different logos, and Chrome being a free ware while Chromium being free and open sourced.

The purpose of this report is to analyze the conceptual architecture of Google Chrome/Chromium. This report looks at the abstract structure as well as its parts and interconnections through extracting information from documentation as well as other scholarly sources. The content can be broken down into sections: high level architecture description, subsystem description, use case and sequence diagrams, architecture style and design patterns, explanation of the derivation process and alternatives as well as lessons learned.

For the architecture and subsystem description, we used the reference architecture of modern web browsers [4] and filled in the case specific details using information gathered from Chromium’s documentation and other various references excluding the source code. It is supplemented with a description of the connections and dependencies between each of the components as well as subsystems. Based on this, we are also able to speculate on the style of architecture used.

Sequence and use case diagrams are then presented detailing the process of data flow and control aiding in the better visualization of dependencies.

A discussion will follow containing the derivation process, alternatives, as well as lessons learned through this analysis process.

Derivation Process

The derivation process for our proposed conceptual architecture was broken up into three main phases: 1. Understanding what is chrome 2. Understanding the reference architecture 3. Understanding the official Google Chromium documentation as well as external papers and reports.

The first phase was to understand the features, tendencies, and history of Chrome. Doing so gave us an understanding behind the high-level design philosophies behind the browser. Looking at videos and articles that detailed the pre-implementation mind set of Chrome gave us the sense that performance, multiprocessing and stability were top priorities in the browser. After this step, we initially thought that Chromium/Chrome was an object oriented style with some aspects of a repository style. The reason why we thought that it might have been O-O was because of the presence of highly abstracted systems. Another reason is that, because Chrome emphasized stability and performance, it needed multiple instances of components running at once. Our reasoning behind the speculation that it was a repository was that we thought the main display could have been the central shared pool while other components such as the renderer and plugins connected to it.

The second step is familiarizing ourselves with the reference architecture for web browsers in general. The reference architecture provides us a framework for the actual architecture. It simplifies the later steps of looking at the documentation by: Documenting existing well-proven

designs, providing common vocabulary, and aiding in the comparison of different architectures in the same domain just to name a few benefits. The reference architecture for web browsers from “A Case Study in Architecture Analysis: The Evolution of the Modern Web Browser” [4] is shown below:

Reference Architecture of a Web Browser

As will be compared with Chromium’s conceptual architecture, many of the large components such as the UI, Browser Engine, and Rendering engine stay intact.

The third and final phase is looking at the Chromium documentation [3] and filling in the framework created by the reference architecture. Changes were made to tailor the model towards Chrome. This will be explained in the next section.

Proposed Conceptual Architecture

The conceptual architecture was derived by synthesizing the results from all three steps in the derivation process. As mentioned in the previous section, many of the large components such as the UI, Browser Engine, and Rendering engine stay intact. These components are organized in hierarchical structure and with only the component adjacent to each other involved in intercommunication. These layers connect via Inter-Process Communication Pipes or IPCs. This property categorizes the architecture of Chrome/Chromium as a layered style, different from our initial hypothesis.

We do however, retain our initial prediction that the renderer was partly object oriented. This can be shown through the instantiation of render objects every time a new tab is created.

Proposed Conceptual Architecture For Chromium/Chrome

At the highest level, there is the user interface subsystem, which provides an interface that allows the users to interact with Chrome. The UI of Chrome includes the search bar, web site entry, user account, settings and plugins. The layout of the UI can greatly impact the user experience of the application. Chrome’s design philosophy of simplicity and intuitiveness is well apparent in the user interface, with the now common combined search and website entry bar as a prime example.

Below that is the browser engine, which can be thought of as a high-level interface for the rendering engine [4]. The main functions of the browser engine are: managing the instance from rendering engine, displaying the content of web page and also storing the data from user. For example, Chrome can store browsing history, cookie, accounts & passwords and bookmarks via data persistence, and displaying web page through main thread [5].

At the lowest level is the renderer, or the rendering engine. Rendering Engine reads different documents and convert them to in memory elements and combine them with packages to create a visual representation of the content of web page. Chromium uses WebKit as its rendering engine and SKIA for its graphics library [6].

The plugin system gives the Chromium browser additional functionality. [] With the implementation of plugins, it again shows Chrome/Chromium’s emphasis on stability as it is a separate process from the browser and renderers. This ensures a crash in a plug in will not affect the other components and vice versa [5].

Subsystem Decomposition

In this section, we will undergo a deeper analysis of the browser and renderer.

Browser:

Browser Engine

The browser engine in Chromium deals with the instances of each tab or each browser. It manages and stores data like the passwords and bookmarks and communicates with the network and partly handles the plugin interface.

Below are some of the subcomponents of the browser engine [5][7][8][9].

I/O ThreadThis is where ResourceDispatcherHost is located. This is the master dispatcher for all resource requests in all renderers. This can forward resources to other subcomponents inside the browser such as the network stack. This process will be discussed in more detail later.

Main ThreadContains the RenderProcessHost and RenderViewHost. The RenderProcessHost manages the instance of the RenderProcess in each of the instantiated renders while the RenderViewHost manages the instances of the RenderView objects in the renderer. If there are multiple views in a single renderer, they are given a unique view ID to uniquely mark each instance and requires the RenderProcessHost to view and manage the ID.

Data PersistenceThe Data Persistence subsystem is responsible for storing session data such as Cookie, history, password and etc. This resides in the Browser kernel because the renderer processes can be instantiated and killed multiple times throughout a session lifetime and will lose all data if it was placed in there. Separating it from the renderer also maintains the integrity and security of data when the instances are closed as they would be deemed inaccessible by the Browser kernel.

Network StackNetwork stack is controlled by the I/O thread. Network stack allows chrome to send the request to the URL (universal resource locator) and to fetch the resource codes of the URL, in order to display the website. The Network Stack resides in the browser kernel as it needs access to the

network which is a high-privilege operation. The network stack also needs resources distributed from the ResourceDispatchHost, which is also in the Browser Kernel. Chrome used to use WinInet and WinHTTP, but they all had limitations with performance and efficiency. Therefore, Chrome developed their network stack to overcome those limitations. The two main goals were: 1. Facilitate easier cross platform support. 2. Allow for easier debugging for Google Developers.

Renderer:

Renderer

Below is a breakdown of some of the main subcomponents of the renderer [5][6][8][10]

WebKitWebKit is responsible for laying out the webpage. It is based on KHTML program from Apple, and it contains WebCore and JSCore. The main function of WebCore is managing the layout, and JSCore provides the environment to execute JavaScript. Inside WebCore are the HTML, CSS, and XML Parsers which together build a render tree. In 2013, Chrome developed a fork of WebCore called Blink, and has been used instead of WebCore since. Blink contains major parts of WebCore, but it deletes useless code and has added flexibility.

The JSCore contains Chromium’s Java Script Interpreter, V8. Compared to other engines, V8 uses inline caching to achieve the high performance. Inline caching can remember the results from the methods that have been called before and save time when executed. Another advantage is that V8 compiles JavaScript to native code and can execute them as machine code that can be directly executed by computers in order to improve the speed of the runtime.

RenderProcessEach instance of a render process has the object RenderProcess. This object is responsible for managing that specific render process as well as its communication with the Browser Kernel.

RenderViewThis object is responsible for managing the communication between WebKit and the Browser Kernel. RenderView contains the webpage content. There can be more than one RenderView instance per render process and is managed by the RenderProcess object.

SKIASKIA is the graphics engine that is used by Chromium/Chrome, which provides graphics and animations in the renderer. When the RenderProcess sends requests of graphs, a tag in HTML files called a canvas allocates an area that the graphics will reside in. Then SKIA generates bitmap files, and Webkit uses bitmap files to draw in that area.

SecurityAs touched upon earlier, there can be multiple renderers (or render processes) in Chromium. Just like many of the other components in Chromium, the renderer also has a strong focus on stability, security, and integrity. In Chromium these render processes are tab specific, therefore ensuring that a single tab crash would less likely affect the entire application. This is also why the three web code parsers are integrated into each of the renderers as opposed to separate entities (which was the case in the reference architecture. To protect the integrity of the global filesystem as well as the network data in the event of a crash, a render process’ access to these resources are restricted. This is achieved through sandboxing, where certain resources such as network data can only be accessed by the render process through its own parent process. There are also OS level security measures to prevent against persistent changes to the host computer.

Plugins:

Plugin System

There are two types of plugins, in-process plugin and out-of-process plugins.The plugin processes all start in the renderer. WebKit implements the plugin interface in the renderer. But the difference between in-process plugin and out-of-process plugin is that in in-process plugins, the implementation starts in the renderer and directly talks to the plugin API wrapper. To be more coherent with the multi-process nature of Chromium, plugins can also be executed out-of-process. In out-of-process, the implementation also starts in the renderer, but implementation is transferred to the Plugin system via IPC then talks to the plugin API wrapper. The out-of-process plugin also allows the sharing of the NPAPI code to every render process.

The plugin subsystem is connected to each of the renders using IPCs via the PluginChannel object on the plugin side and the PluginChannelHost on the renderer side. There will be one PluginChannel per renderer that is using that plugin. [7]

Use Cases

Below are two sequence diagrams to show the flow of data through the system.

The first use case is: User logging in to a website and succeeding and Chromium saving the password.

1. User enters the URL of the website from the user interface.2. User interface requests login page from the browsers.3. Browser gets the resource of the website from the third-party website through the

Network Stack, and then sends the data to the renderer.4. Renderer renders the data form browser and passes it to SKIA.

5. SKIa paints the graphic information and sent it back to renderer, renderer returns the data to the browser kernel.

6. The user interface loads the login page from the browser.7. User gets the view of the login page.8. User enters the account and password from the login page.9. Browser gets the resources of the website from the third-party website through the

Network Stack.10. Renderer gets the information from browser and check if the information gets from

network matches the information of uses entered. If they are matched, render return ok to browser, and browser sent the data to render in order to get the graphic view from SKIA.

11. Under the user’s permission, the browser will save the user’s information to data persistence and returns the successful notice to the user by rendering the graphic from SKIA.

The second use case is: Chromium rendering a page that has JavaScript

1. User enters the URL of the website from the user interface.2. User interface requests page from the browser.3. Browser gets the resources of the website from the third-party website through the

Network Stack, and then sends the data to the renderer.4. Renderer sends the JavaScript code to JavaScript V8 to be interpreted.5. V8 returns the result to renderer.6. Renderer renders the data form browser and pass it to SKIA.7. SKIA paints the information and sends it back to renderer, 8. Renderer returns data to browser.9. User interface loads the page from the browser.

10. User gets the view of the page.

Concurrency

Concurrency is the ability to execute different parts of a system in any order without affecting each other or the final outcome. This allows for parallel execution of threads or processes in a web browser, which will significantly improve overall speed of the execution in multi-process and multi-threaded architectures [12].

Chrome uses a multi-process architecture. A multi-process architecture allows for concurrency within the web browser such as using multiple renderers to create different tabs. Each renderer process is run in a sandbox [5]. Each tab is its own process, so we can restrict its access to system resources via sandboxing. Running each tab in a separate process allows Chrome to provide more security against page rendering bugs, as well as browser plug-in bugs. If a tab crashes, it won't affect other tabs.

The processes in Chrome employ a multi-threaded architecture. What multi-threading allows for is concurrency within each process. Every process in Chrome has a main thread, an I/O thread and other general-purpose threads. Every thread has its purpose and are run at the same time for concurrency benefits [11]. For example, the main thread in the browser process updates the UI and the I/O thread handles IPC and network requests.

Multi-threading and multi-processing are not the same thing. A multiprocessing system executes multiple processes simultaneously whereas, a multithreading system executes multiple threads of a process simultaneously. The benefits of multithreading are increased significantly in a multiprocessing environment as multithreading on a multiprocessing system increases concurrency even more [11].

Concurrent code compilation is another step towards reducing latency in Chrome and is part of various ongoing efforts to deliver more responsive, smoother web applications. The Javascript interpreter V8 took turns compiling optimized Javascript code and executing it. For large pieces of code this could become a nuisance, and in complex applications like games it could even lead to stuttering and dropped frames [12].

Concurrent compilation tackles this issue. By enabling concurrent compilation, V8 still optimizes a large piece of code, but does it in a background thread. Execution continues alongside compilation, providing for a smoother user experience.

Team Issues

It was the first time building a multi-process architecture browser for the Chrome team. In the early days, the browser renders all the pages you visited in the same process, to keep resource usage low. It was a challenge at that time to implement a multi-process architecture that would support concurrency.

Before Chrome, plugins were a major source of instability. Older browsers had the plugins run in the browser kernel, which means that any leaks or crashes in the plugin would affect the entire browser. Chrome decided that they would separate the two systems. This required the architecture to add a new “plugin” subsystem, which was difficult in a single process architecture.

Lessons Learned

From this analysis we have learned lessons in different aspects: lessons about Chromium, lessons about browsers in general, as well as lessons regarding architecture analysis.

We learned that stability, security and integrity were points of heavy focus for the Google development team. Every component in Chromium was built so that a crash in one of them will not crash the entire system.

In terms of browsers in general, we learned the importance of multi-processing. Not only does it facilitate integrity, it also allows for concurrency, which is crucial for the multi-tab and multi-view performance that we find in modern browsers.

In terms of architecture analysis in general, we learned that the reference architecture structure can still be subject to significant changes in specific implementations, examples being Chromium integrating the network stack into the browser kernel and combining the three web data parsers into the renderer.

Conclusion

In this analysis, we proposed that Chromium/Chrome is a layered style combined with some object-oriented aspects in the lower level subcomponents. Through the deeper analysis of the browser and renderer components, we found that it was catered towards multiprocessing, some of the hints were: ability to run multiple independent renderer objects, sandboxing each render process so that only certain data can be accessed, higher abstraction control layers for the objects inside the renderer, etc.

For the next step, we will look into the actual code of the subsystems to achieve a greater understanding of the classes and their connections. One in particular is how SKIA actually fits in the renderer. Overall, this provides a good frame work to fill in.

Glossary

- Webkit: The open source rendering engine provided by Apple, contains WebCore and JavaScriptCore.

- WebCore/Blink: Reads files from HTML, CSS, XML parser to get the content and style of a web page. Google developed Blink to replace WebCore.

- HTML (Hypertext Markup Language) parser: Compiles HTML files to get the content of a web page.

- CSS (Cascading Style Sheets) parser: Compiles CSS files to change the style of one web page.

- XML (Extensible Markup Language) parser: Provides a way to transfer and store data.- DOM (Document Object Model) tree: Each element contains different parts (div,

paragraph) of web page with style attributes (color, size).- SKIA: A graphic engine to help provide graphs and animations, used by Windows and

Linux only.- Canvas: A tag in HTML files, used to specify an area for graphs.- Bitmap: Image file with filename extension .bmp or .dib.- V8: JavaScript Interpreter developed by Chromium project, provides an environment to

execute files.- Render Process: Manages communication between renderer and browser.- RenderView: Represents the content of one web page.- ResourceDispatcher: Sends and receives requests from browser.- IPC: Inter Process Communication: a data transition pipe in Chrome.- RenderProcessHost: In Main thread in Browser. It connects with RenderProcess with

one-to-one relationship and handles the RenderProcess.- ResourceDispacherHost: In I/O thread in Browser. It handles all the requests within the

whole system.

- RenderViewHost:– In Main thread in Browser. It connects with RenderView with one-to-one relationship and Display the RenderView.

- WinInet: The Windows Internet. An API allows applications to connect to Internet with HTTP

- WinHTTP: Microsoft Windows HTTP Services. An API allows applications to connect to Internet with HTTP

- NPAPI: Netscape Plugin Application Programming Interface. An API allows plugin connecting with browser

References[1] 2018, G. (2018). Most popular internet browser versions 2018 | Statistic. [online] Statista. Available at: https://www.statista.com/statistics/268299/most-popular-internet-browsers/ [Accessed 15 Oct. 2018].

[2] Kennedy, N. (2018). The story behind Google Chrome. [online] Available at: https://www.niallkennedy.com/blog/2008/09/google-chrome.html [Accessed 15 Oct. 2018].

[3] Chromium.org. (2018). Chromium - The Chromium Projects. [online] Available at: https://www.chromium.org/Home [Accessed 13 Oct. 2018].

[4] Rosskurth, A. and Godfrey, M. (2007). A Case Study in Architectural Analysis: The Evolution of the Modern Web Browser.

[5] Chromium.org. (2018). Multi-process Architecture - The Chromium Projects. [online] Available at: https://www.chromium.org/developers/design-documents/multi-process-architecture [Accessed 16 Oct. 2018].

[6] Chromium.org. (2018). Graphics and Skia - The Chromium Projects. [online] Available at: https://www.chromium.org/developers/design-documents/graphics-and-skia [Accessed 15 Oct. 2018].

[7] Chromium.org. (2018). Plugin Architecture - The Chromium Projects. [online] Available at: https://www.chromium.org/developers/design-documents/plugin-architecture [Accessed 14 Oct. 2018].

[8] Chromium.org. (2018). Multi-process Resource Loading - The Chromium Projects. [online] Available at: https://www.chromium.org/developers/design-documents/multi-process-resource-loading [Accessed 17 Oct. 2018].

[9] Chromium.org. (2018). Network Stack - The Chromium Projects. [online] Available at: https://www.chromium.org/developers/design-documents/network-stack [Accessed 14 Oct. 2018].

[10] Chromium.org. (2018). How Chromium Displays Web Pages - The Chromium Projects. [online] Available at: https://www.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome [Accessed 14 Oct. 2018].

[11] Chromium.googlesource.com. (2018). Threading and Tasks in Chrome. [online] Available at: https://chromium.googlesource.com/chromium/src/+/lkgr/docs/threading_and_tasks.md#Threads [Accessed 16 Oct. 2018].

[12] Chromium Blog. (2018). Compiling in the background for a smoother user experience. [online] Available at: https://blog.chromium.org/2014/02/compiling-in-background-for-smoother.html [Accessed 15 Oct. 2018].