Slashdot Mirror
Firefox Takes the Next Step Towards Rolling Out Multi-Process To Everyone (arstechnica.com)
An anonymous reader quotes a report from Ars Technica: With Firefox 50, Mozilla has rolled out the first major piece of its new multi-process architecture. Edge, Internet Explorer, Chrome, and Safari all have a multiple process design that separates their rendering engine -- the part of the browser that reads and interprets HTML, CSS, and JavaScript -- from the browser frame. They do this for stability reasons (if the rendering process crashes, it doesn't kill the entire browser) and security reasons (the rendering process can be run in a low-privilege sandbox, so exploitable flaws in the rendering engine are harder to take advantage of). Moreover, these browsers can all create multiple rendering engine processes and use different processes for different tabs. This means that the scope of a crash is narrowed even further, typically to a single tab. Internet Explorer and Chrome both implemented this long ago, in 2009. Firefox, however, has not offered a similar design. Although work on a multi-process browser was started in 2009, under the codename Electrolysis, that work was suspended between 2011 and 2013 as priorities within the organization shifted. In response, Mozilla started switching to a new extension system in 2015 that opened the door to a multi-process design. The first stage of Firefox's move to multi-process involves separating the browser shell from a single rendering process that's used by every tab. In Firefox 48, that feature was enabled for a small number of users who used no extensions. Firefox 49 was rolled out to include users running a limited selection of extensions. Now, in Firefox 50, a separate renderer process is used for most users and most extensions. Developers are now able to mark their extensions as explicitly multi-process compatible. Firefox 51 will extend this even further to cover all extensions, except those that are explicitly marked as incompatible. Mozilla says that, even with the limited changes made in Firefox 50, responsiveness of the browser has improved by 400 percent due to the separation between the renderer and the browser shell. During page loads, responsiveness will increase to 700 percent.
Isn't that the browser a lot of people used to use before the developers decided to wreck just about everything they liked in order to turn it into some kind of inferior imitation of Chrome?
I've calculated my velocity with such exquisite precision that I have no idea where I am.
It's actually something they're investigating for Firefox right now, and one of their focuses for the whole Project Quantum thing seems to be to try to reduce the amount of CPU usage that background tabs get (unless it's somehow clear that they're supposed to be working in the background without being slowed down too much). Hard to say what the results will be at this early stage, but there's a lot of interesting stuff that seems possible now that they've rewritten most of the browser to support e10s.
last I heard they were going to break it with version 40 sometime in August. There's a ton of work that'll have to be done to make it work properly in a multi-process environment. More or less a full re-write. To say nothing of having to redo all my UI components. Here's hoping they get cross compatibility with Chrome so I can at least get some code reuse out of it.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
You can control how many sub-processes are created by the browser using an entry at the about:config screen. If you set it to one it will only spawn one sub-process. This will of course negate the whole idea of having sub-processes since all tabs would be running in one rendering sub-process but it would fix your issue.
We're going to fix that problem in my first 100 days in office, believe me. DNS is low energy and high latency, SAD! Did you know there are DNS servers in Mexico and CHY-NA, folks? I'm going to make it ILLEGAL and force every link on the cyber to go through my new URL shortening service, HTTP://BIG.LY. I'm appointing Barron to run it so you know it's going to be the best!
I've been using Firefox 51 from the firefox-next PPA in Xubuntu on a 1-core, 2-thread Atom N450 laptop for a couple weeks now. Even if all tabs run in one process, scrolling still runs smoothly because it's in a separate process, though occasionally I outrun the rendered portion and there's a delay before the blank part fills in.
I suggest you look at cgroups. Instead of relying on the processes to play nice with resources, you can specify the resources you want allocated to each user. For instance, if each user has cpu.shares=1024, then it'll fully balance - if user A starts an old firefox and it's running singlethreaded, and user B starts a new firefox and it spawns 50 processes, you'll see user A's process consuming 50% of CPU, and user B's flock consuming 1% CPU each.
In this way you specify what you want to achieve (user B doesn't steal all the CPU making life suck for user A), instead of how to achieve it (singlethreaded software, and relying on users to not run more than one copy). It's easier and more efficient.
The other cool part: this may already be set up for you. On my Ubuntu 14.04 system this is all done by default when I log in.
I'm curious, in what way does turning threads into processes overrun CPU resources? Threads can peg the CPU meter on multiple cores just as easily as processes can. Is it a page table thing or an OS scheduler thing or what?
It seems to me that you have an operating-system level problem. If nice and ulimit and the OS scheduler aren't cutting it, then they need to be improved or replaced.
They can't win. If they don't do it, Firefox's performance and security will continue to fall behind and the vast majority of users will complain. If they do it, a small number of users with unusual use-cases will complain that it breaks their system. If they try to accommodate both it will create much more work and delay the feature.
Oblig. XKCD.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Firefox doesn't leak memory these days. Some add-ons do, but that's the add-on developer's fault. Part of the trade-off for having powerful add-ons with deep ties into the browser is the risk of memory leaks and security issues. Chrome is much more restrictive and aggressively manages add-ons, but even there you can get memory leaks with Javascript heavy sites like GMail.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I'm glad they're finally giving each tab its own process. Of course, if they didn't they'd wind up in the dust bin of history... its about the minimum of work they need to do just to keep Firefox relevant. There is much more they need to do in addition. Honestly, Firefox's biggest competition here, after fixing the tab problem, is going to be chrome 55 with its significantly improved (reduced) memory footprint.
The interesting thing about giving each tab its own process is that although this increases the total amount of memory used by the browser, it also has the effect of reducing the memory fragmentation that forces the OS to keep almost every byte of it in core (Firefox is best known for this effect). With the process separation, the OS will have a much easier time paging out unused memory without nominal browser operation forcing every single last page back in. THAT is a big deal, and is one of the reasons why chrome is so much more usable than firefox.
I regularly leave my browser(s) running for weeks. Process sizes generally bloat up during that time, to the point where the browser is consuming ~8GB+ of ram. With Firefox the horrid memory management in-browser forces most of that to stay in core. With chrome, most of it gets paged out and stays out. This makes chrome far more usable, particularly considering the fact that my workstation runs from a SSD and has a relatively large (~60G) swap partition configured.
But these days I'm a chrome user. Firefox has been too buggy for at least the last 4 years. It crashes on all sorts of things, taking the whole browser out with it. And after all this time they *STILL* can't fix the idiotic pop-up windows. Disable popups only disables some of them. That and the bugs is the main reason why I stopped using Firefox.
In terms of sandboxing... also a good thing. In addition to the work the browser does, I also segregate my browser instances into multiple dummy user accounts (that my GUI buttons can just ssh into from my main account), and run multiple instances of the browser from those. One for unsecure browsing, one for browsing important accounts, and one with the most bulletproof setup I can think of (no video group access, no direct X server access)... which is slow, but about as safe as its possible to be in an X environment.
People often forget about user account separation. It's a bit sad.
-Matt