Web lists-archives.com

Re: Electrolysis




I'll attempt to answer some (but probably not all) of the questions.

In article <ObudnUGffuXicXfEnZ2dnUU7-TvNnZ2d@xxxxxxxxxxx>, 
jbbrus@xxxxxxxxxxx says...
> 1. In Options-General, what does "Content process limit" actually mean? 
> For example, mine is set to 4 but I see as many as 7 FF processes in the 
> Window's task manager.

The "Content process limit" limits the number of Firefox content 
processes. Roughly, you can think of a "content process" as a process 
that interprets and renders a web page, essentially what renders the 
content of a tab or multiple tabs.

If working on multiple tabs, a content process may delay rendering one 
tab while it is busy working on another tab. So a complicated page or a 
page that is JavaScript-heavy may cause delays in rendering other tabs. 
(The long-term plan is to use multiple simultaneous threads to allow 
multiple pages to be worked on simultaneously by the same process, but 
as of today a process can work on only one page at a time.)

If using multiple content processes, if a content process is busy with 
one web page / tab, it won't hold up another content process assigned to 
other tab(s).

I have a web page I frequent several times a week that takes 35 seconds 
in Firefox Nightly to render, and rather than hold up other tabs for 
that 35 seconds, I use dom.ipc.processCount = 10 so I can use 9 other 
content processes for up to 9 other tabs while one of those content 
processes is busy with that one long-time-loading page. (If I have a 
smaller limit on content processes than I have active tabs, some content 
processes will handle two or more tabs, running the risk that I might 
want to interact with a tab when that tab's process is busy rendering 
that 35-seconds-to-load page.)

If a content process crashes, only the tab(s) controlled by that content 
process crash, while the rest of Firefox should be able to keep on 
running.

Those are content processes: rendering one or more tabs.

There are other processes Firefox uses, but are _not_ content processes.

The main/UI process. When you start Firefox, it starts the main/UI 
process, which launches and coordinates the other processes, and which 
also runs the user interface.

The gpu process. If using hardware acceleration, a gpu process is 
launched to interact with the gpu. If the gpu process crashes, Firefox 
is suppose to fall back to non-gpu code.

If using Flash, Firefox will launch a process (formerly called a 
"container") to run Flash, so if Flash crashes it doesn't crash other 
parts of Firefox.

More recently, Firefox has been using a process for running extensions. 
This is a "sandbox" feature that further isolates extensions from the 
rest of Firefox, working only with WebExtensions.

Since "Content process limit" only limits the number of content 
processes (you can have fewer if you have fewer tabs open), the other 
Firefox processes are handling other things (main/UI, gpu, Flash 
container, extensions sandbox).

Each process can have one or more threads, but the operating system sets 
permissions, resources, handles at the process level, but schedules 
execution of instructions at the thread level. Theoretically, a process 
can have multiple threads ready to run and the operating system would 
schedule those threads in available cores of the CPU. However, because 
of the way the Gecko engine was originally written, much of the content 
process has to run as if there were only one core (the rewrite in Rust 
should eventually remove this restriction), so to render multiple pages 
at the same time one can use multiple content processes, each content 
process using a slice of a different core at the same time, the net 
effect is that multiple content processes can use multiple cores to 
simultaneously render multiple web pages. But if there are more threads 
ready to use the CPU than there are cores, the operating system will 
first run those threads with a higher priority and, when there are more 
threads ready to run at the same priority than there are available 
cores, will time-slice between them. (The exact details may vary between 
operating systems.) In addition to rendering, the main/UI process will 
also use CPU cycles to display the status of the tab (the "throbber" for 
loading a page, for example), and give you tab-level control (closing a 
tab, opening a new tab, running an internal page like 
about:performance).

I know only a little bit about the Intel hyper-threading models and I 
doubt that I could provide anything meaningful there, except to state 
what the CPU documentation means by hyper-threading doesn't mean the 
same thing as a thread when speaking of a process; to the program the 
hyper-threading (when enabled) just looks like more cores.
_______________________________________________
general mailing list
general@xxxxxxxxxxxxxxxxx
https://lists.mozilla.org/listinfo/general