[3] chrome Process Model 1. the basic process structure Chrome is a multi-process architecture, but all processes will be managed by the boss and the browser process, taking the path of centralized management. In the browser process, there are xxxprocesshost,
Each host corresponds to a process For example, renderprocesshost corresponds to renderprocess, pluginprocesshost corresponds to pluginprocess, and number of processes are running on the number of host instances... This is a typical proxy mode. All browser operations on the host are encapsulated by the host as an IPC message and passed to the corresponding process for processing. For most upper-layer classes, the multi-process details are isolated... 2. The render process only considers the render process. As mentioned above, a process and a tab are just advertisement terms. In fact, the content of each web page (including the content in the tab and in the pop-up window ...), in Chrome, renderview is used to represent a Web page. Each renderview can host any renderprocess. It only relies on renderprocess to help communication. Each renderprocess can have 1 to n renderview instances... Chrome supports different process models, including a tab, a site instance, and a process. However, the basic modes are consistent,
When you need to create a new renderview, chrome will try to select or create a process . For example, in one site one process mode, if this site exists, an existing renderprocesshost will be selected to manage the new renderview. Otherwise, creates an renderprocesshost (a process is also created), and The renderview is handed over to it... In the default one site instance one process mode, chrome creates a process for each new site instance (a page that is linked from a page, belongs to the same site instance ), however, the total number of render processes is limited. This limit varies depending on the memory size. For example, on my machine (2 GB memory), it can accommodate up to 20 render processes,
When this limit is reached, you can open a new website. Chrome will randomly select an existing process for you and throw the renderview corresponding to the website. ... Each time you enter a new site information, in the default mode,
It will inevitably lead to the birth of a process. It is very likely that, along with the death of another process (If the process does not carry any other renderview, it will naturally die. The number of renderview is equivalent to the reference count of the process ...). For example, when you open a new tab, the system creates a process for you to carry the new tab, and you enter www.baidu.com, so the new tab process dies and the process carrying www.baidu.com is born. You searched with Baidu. Without a doubt, you are very disappointed with the search results, so you re-enter www.google.com, and the old process carrying Baidu died, google processes are built. At this time, you want to roll back to the previous Baidu search results. If you are happy, a new process carrying the Baidu will be created, and the previous Google process will die. Similarly, when you click forward again and return to Google's search results, a new process replaces the old one... You can test the above phenomena by yourself. By observing the information on the about: Memory Page, you can understand the entire process (remember to refresh the about: Memory Page for every step ). I have been talking about it for a long time. What I want to express is,
Chrome does not have a special mechanism such as process pool like my YY, but simply implements a policy of creating and destroying a process pool. . I don't know whether there is a very effective multi-process model, and I have never played it in this aspect. I guess that Chrome adopts such a strategy after thinking that the price of process life and death can be borne, more feasible... 3. process overhead Control Algorithm There are two aspects of Overhead: time and space. Chrome does not work hard on process creation and destruction, but when the process runs, it still does some work... To save work, we start from CPU time consumption. The higher the priority of the threads in the process, the easier it is to be scheduled, which consumes CPU time. Therefore, when a page no longer directly faces users, chrome switches the priority of its processes to the level of below normal, and vice versa, switches back to the normal level. This step saves a little time...
process priority
in windows, a process has a priority. Of course, this priority is not a real scheduling priority, it is the benchmark for calculating the thread priority in the process. In Windows via C/C ++ (the fifth edition of Windows core programming), there is a detailed table, I have expressed the Specific correspondence between thread priority and process priority. I feel that the design is very good. I will not copy it. If you are interested, I will flip the book on my own...
& Lt; TD width = "100%" & gt;
Of course, this is just an appetizing dish. The full Chinese banquet controls the working set size of the process to reduce the actual memory consumption of the process (chrome aims to reflect its memory savings, the "more accurate" memory consumption calculation method is used ...). Speaking of this, Chrome is very proud. In this document, the single-process mode is despised. The basic meaning is: in the multi-process mode, the actual amount of memory occupied by each page is more easily controlled, but in single-process mode, it is almost impossible to control it. Therefore, in many cases, the memory consumed by the multi-process mode is, is smaller than the multithreading mode. This statement is not reliable, and everyone is familiar with it, so I won't say much... Specifically, Chrome's Control Algorithm for the process's working sets is relatively simple. First, when starting a process, you must specify the memory environment in which the process is working, such as high memory, low memory, or medium memory. In the default mode, it is medium memory (I thought chrome will calculate it dynamically, but I didn't expect it to be specified at startup ...). In the high-memory mode, there is no adjustment to the working set, so it is easy to use it. In the low-memory mode, the adjustment is also very simple. Once a process no longer has pages to face the audience, try to release all of its working sets. In contrast, in the medium mode, the algorithm is relatively complex. When a process changes from directly facing the audience to the miserable fate of switching to the background, its work assembly is reduced. The algorithm is: Targetworkingsetsize = (lastworkingset/2 + currentworkingset)/2 Specifically, targetworkingsetsize refers to the expected workset size, and currentworkingset refers to the current working set of the process (in chrome, the working set size, including private and shareable memory, but not shared memory ...), lastworkingset is equal to the previous currentworkingset divided by dampingfactor. The default dampingfactor is 2. On the contrary, when a process moves from behind the scenes to the stage, its work assembly is enlarged Lastworkingset * dampingfactor * 2 You know the meaning of lastworkingset. This is an alternative version that doubles the working set... The working set of Chrome's render process is adjusted. In addition to Tab switching (or new page creation), it will also happen after the entire chrome idle event is triggered. . Chrome has a timer to count the idle duration of chrome. After the timer length exceeds 30 s (this job will be done repeatedly ...), chrome will do a series of work, including adjusting the working set of the process. The adjusted process is not only a render process, but also a plugin process and a browser process. In other words, it is all chrome processes... This algorithm leads to a very miserable situation. When you go to a restroom and return to the computer, you switch to a chrome page. You find the page is pale and after a storm of hard disks, it was hard to restore the original appearance. If you switch again, the same thing will happen again, and you will never stop until you switch through every process. The main cause of this tragedy is Since the working sets of all chrome processes are released, page overloading and render takes a lot of time, which greatly affects user experience. After all, it is easy to see pale pictures, which may lead to bad emotions. It is strongly felt that this is not a very good strategy. There should be a limit for switching the working set, or when Chrome is activated from idle, it secretly expands the working set, trigger several events and load the loaded items... The overall feeling is that Chrome's control over process overhead is not as brilliant as it is imagined. Working sets are not a great way. If you want to work well, there is a very important premise, Is the page to be switched and rarely browsed. . I personally think this assumption is not very reliable, which leads to a very bad User Experience in some cases. Maybe chrome needs to learn more about the method here...
