Slashdot Mirror
Firefox To Get Multi-Process Browsing
An anonymous reader writes with news that multi-process browsing will be coming to Firefox. The project is called Electrolysis, and the developers "have already assembled a prototype that renders a page in a separate process from the interface shell in which it is displayed." Mozilla's Benjamin Smedberg says they're currently "[sprinting] as fast as possible to get basic code working, running simple testcase plugins and content tabs in a separate process," after which they'll fix everything that breaks in the process. Further details of their plan are available on the Mozilla wiki, and a summary is up at TechFragments.
This is cool. Competition is good.
Mozilla's Benjamin Smedberg says they're currently "[sprinting] as fast as possible to get basic code working, running simple testcase plugins and content tabs in a separate process," after which they'll fix everything that breaks in the process.
This sentence was a little hard to process.
(I note that the "process" of Slashdot incremental improvement has now reached a point where clicking anywhere in the text-entry box causes the box to LOSE focus. If you don't want us using Safari, there are more efficient ways to get us to move.)
I was concerned that Firefox wasn't using as much of my system's RAM as it could. I bought 8GB, and I intend to use it.
In all seriousness, this is good. It should handle crashes and frozen processes better, like Chrome.
Thanks google, and thanks mozilla, for helping to drive competition and make the web browser better.
You see? You see? Your stupid minds! Stupid! Stupid!
They've effectively been there already. It was when Netscape started talking about the browser being the "new desktop" that Microsoft started to see them as a serious threat. Cue the purchase of Spry Mosaic, its rebranding as Internet Explorer and attempt to extinguish Netscape by bundling it with Windows.
What took so long?
Yeah! All they had to do was change their entire codebase from around 5+ years of Firefox (and probably more of Mozilla/Netscape) to update it! That's, what, half an hour's work? And don't give me this "legacy code" bullshit; if they bothered to anticipate our fifty bajillion core processors back then like any NORMAL person should today, they wouldn't be in this mess!
Lazy bastards. I mean, how hard is it to change what is apparently that one really trivial-to-find call in their code to useProcessSeparationOhAndIAlsoWantAPony(true)? Took them long enough...
Actually, they're talking about multiple processes, not multithreading. Threads all belong to a single process, which, if it crashes, will bring down all of its threads. Running the shell in one process, then each tab/window in its own process means that, much like Chrome, a single page can't bring down the myriad of tabs/windows you might have open, if you browse the web like I do.
-Matthew Riley "TofuMatt" MacPherson
I have a website
Most of the people are still running a single core CPU.
And if we could remove Adobe Flash player we would never need a second CPU.
Love many, trust a few, do harm to none.
According to the Ars coverage:
It was probably too large a project to consider doing without a pressing need. Chrome and IE8 supplied that pressure.
The Rise and Fall of Online Community
Really. And all this wouldn't even be a problem if they just wrote it in Java to begin with.
This is why we can't have nice things.
The 'multithread bandwagen'? Multithreading is not just some temporary hype that will be gone and forgotten next year. It is A Good Thing. If they get it right it'll be a big improvement to the browser.
Having said that, your concerns that it may be a pain to implement in a browser that was not designed to support them are valid. While I expect them to succeed, you can always stick with an older (single-threaded) version for a while while the most problematic bugs get fixed.
So your single-core cpu is only ever capable of running a single process? The advantages of a multi-process browser go way beyond running the processes on separate cores.
Competition from Chrome was a good thing: first the Javascript improvements, now separate processes for the plugins.
Hands in my pocket
They want separate processes as a crutch to deal with memory leaks ... the idea being the leak would be contained to one tab's own process rather than the entire browser, and when you close the tab, you close the process.
Wow. The Firefox developer community really doesn't care much for its users, does it? I've interacted with them in small ways in the past, and this verification of my suspicions only supports the dim view I take of them.
They had to chance a code base from around 5+ years only because they didn't things right 5+ years ago. Remember, back then they were doing a complete code rewrite anyway.
And no, the true reason to do this is not multicore. That it also gets faster on multicore is just a nice side effect. The true reason to do it is stability. If one page makes problems, you don't lose all the others. This was indeed even more important back when browser and mail was the same program, because it meant that a page crashing your browser could destroy your almost-completed email, too (yes, this has happened to me, although I'm not sure if it was still old Netscape or already new Mozilla). Of course, today it's quite possible that your browser is your mail client again because you're using webmail.
Note that if it were just a performance thing, they could have gone multithreaded instead. This would probably get even better performance.
The Tao of math: The numbers you can count are not the real numbers.
Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.
The Microsoft folks don't seem concerned about this, at least not concerned enough to implement it in IE. While I don't doubt that Windows processes are fairly heavyweight, I doubt that they're big enough to cause trouble until the user has hundreds of tabs open.
Why not just have rendering worker threads? Have I missed something?
Although working in multiple threads can increase performance in much the same way that multiple processes can, that's not the major benefit of the multi-process architecture. The big benefit to multiple processes is that if one of them dies for some reason, the other processes don't go down, and so the user can (mostly) continue to work. Threads can't do this, because all the threads are still part of a single process.
>Most of the people are still running a single core CPU.
Do not confuse multi-process with multi-processor (or multi-core).
Even a single core machine can make use of multiple tasks, or threads, or processes, to get more work done while waiting for one task to complete.
When monolithic code reaches a point where it is waiting for data from the server, it stalls. Multiprocess code has another process it can put to use rendering the images, or playing the goddamed flash.
The clowns working on Firefox had years, YEARS, to get their act together and rewrite the STINKING PILE OF SHIT that is the Firefox codebase. But they chose to flame anyone who dared talk about the massive architectural problem in the absurdly outdated Firefox process model.
Memory protection for each tab? Not possible! Stop asking for something that can't be done! They cried!
Threading for Javascript? Not possible! Stop asking for something that can't be done! The Firefox devs cried!
That is why those AC posts from Firefox devs were so vicious and venomous for everyone pointing out the massive memory/resource leaks in Firefox that have only been somewhat lessened in the latest versions. The solution for those problems involves a complete rewrite of the process and memory model for Firefox.
Now Google came out and humiliated the Firefox devs with Chrome and its amazing realworld threaded Javascript and memory and process protection/isolation.
Nothing but pity and absolutely no sympathy for anyone faced with retrofitting Firefox into a semblance of a modern browser architecture.
Now with full extension support in Chrome this is like hearing about Microsoft scrambling to fix their massive security problems in IE long after you dumped it.
This isn't really about CPU/Core counts, having tabs/plug-ins running in a separate process is useful because if that page/plug-in crashes that process, the remaining pages won't be effected. I highly doubt they will be dabbling with being able to set which processor a certain process runs on (just yet).
This won't really make use of extra processors/cores, that's what threads (should) already do, even if the application doesn't have any special code to do so.
Yes, back in the days when a bad web page would crash your browser this was bad, but I have not seen those crashes recently.
Do you run a lot of plug-ins, by any chance? Browser makers don't control plug-in code (other than the code for their own plug-ins, of course), but this code is still capable of taking out a browser process if it goes bad.
If the browser is stable, what benefit do multi-processes have?
The other big benefit is that one process can't hog the CPU: even if one page gets into a ridiculously tight JavaScript loop that bogs that page down, the others should continue to load.
Still, the "if the browser is stable" issue is a very big if, and as I mentioned above, it's not completely under the browser maker's control.
Also, and maybe I should read the details, but if I am authenticated to a website in one tab, does that authentication carry over to other tabs using other processes?
It depends on how the browser is written, but it can be done.
For users with anything pre-multi-core (and that's only a few years old), this will result in things getting *slower* because of the process overhead. I hope it senses resources and optimizes appropriately, or all of the friends and relatives I tech-support will be cursing me when the update happens. Some of them are already ticked that when they double-click on the Firefox icon, it takes longer to load than IE because of all the update-phone-home (the sort of thing for which we would all get annoyed at M$).
Eventually we'll get to the point where the window comes up and it takes a ludicrous time to fill . . . just like Windows already does now.
Better philosophical architecture is a good thing. Running well in the practical typical system, in front of the average user, is good too. Disruptive change is not always the way to please your users.
if they bothered to anticipate our fifty bajillion core processors back then like any NORMAL person should today, they wouldn't be in this mess!
Processes don't offer more multicore support than threads. What they do offer is clean separation of code that can run independently.
It was probably too large a project to consider doing without a pressing need.
Cuz yeah, Flash locking up the entire browser wasn't a pressing need until IE8 and Chrome. Riiiight.
LOTS of us have been asking about this for a VERY long time (years). Leaving it this late is called 'lack of vision'. This should've been in the very first version. Now there IS a ton of code to make this work with. I imagine that's why they call this Electrolysis...it's a hairy problem now that it's been ignored for so long.
I'll bite. It's about time.
Even explorer.exe is able to open directories using different processes, if you want. Frankly, I found it frightfully annoying to have X+ tabs open and have ONE of those tabs cause the entire program to crash, usually due to a plugin issue. Made no sense to me. Multi-process/multi-threaded/multi-whatever programming has been around for quite a while now, and multi-core cpus have been pretty common, too.
It's one of the huge advantages that I saw with Chrome (over Firefox). That and program open/new tab open speed. FF 3.5 seems to have addressed this somewhat, but it's still slower, I think.
Hooray for competition, and hooray for finally taking advantage of the hardware out there. Really, for one of the most used applications someone will use, it seems silly to only allow it to use a single-process model.
If that's the case, then you were doing something wrong. Firefox rarely uses more than 300mb of memory on my machine and tends not to crash either definitely not 2 to 3 times a day. Also, if you're only using it for 2 or 3 minutes a day, you're clearly doing something specifically to make it crash, because I've had this window open for multiples of that time right now and it has yet to crash
It's become common place for people to blame Firefox for things like Flash crashing or the gunk that comes from browsing. I've been browsing for some time with noscript and without flash and I rarely end up with this kind of trouble. On top of that I have the cache, cookies and history cleared upon exit. And I'm not having any sort of trouble of the sort you're describing.
I don't mind people criticizing Firefox, but this immature trolling because of your own incompetence is enough to make one slightly annoyed.
One way to implementing multi-process Firefox is first allow XPCOM to work across process. i.e. allow objects to be via XPCOM that are actually spawned in another process, one explicitly created for the task. In COM it had a thing called a running object table (ROT). When you create a process hosted object it looks to see if one is running already, and if not it uses the registry info to spawn one. Then it waits for it to start and then it tells the process to create the object, sets up all the marshaling etc. XPCOM could do something similar, though it would have to do so in a cross-platform manner. I assume that Firefox would have to determine when creating a browser object first if it was chrome or content, and if it was content to spawn a host process and then set up the interfaces. Once set up and assuming the interfaces were efficient, the effect would be largely transparent.
The biggest performance hit would probably be on anything which tried to call or iterate over the DOM boundary between chrome and content. For example chrome which introspected content would suffer because all the calls would have to be serialized / deserialized.
Personally I think its feasible but it would hit performance. An alternative would be to just host plugins in another process. Windowless plugins might be a pain to implement but at least you could kill the other process if a plugin goes nuts which seems to happen all too frequently for me.
This should solve a long-standing bug regarding proxies and DNS.
For whatever reason, if you are using a proxy server (It may only pertain to specific proxy configurations, I'm not sure, I do know that the proxy setup where I work triggers this bug), the whole browser will freeze while a DNS lookup executes. NOT good if you accidentally typo a domain.
retrorocket.o not found, launch anyway?
That sounds like a job for killall!
Funny thing is, they're already in the middle of a major revision project. After Fx2, Brendan Eich released a set of goals for Mozilla 2. The idea is/was to do a large scale cleanup and refactoring (explicitly not a rewrite, however) in order to get rid of some legacy code still around from overly ambitious plans that didn't pan out (e.g. XPCOM). That was to happen in parallel to the development of Fx3 on Gecko 1.9.0.
It's not clear how much progress has been made on Gecko 2.0—almost no public-facing announcements are made about it to the community, and the wiki page is dormant. All the work and focus seems to have been poured into Gecko 1.9.1 (Fx3.5) and now 1.9.2 (Firefox.next).
One element of Eich's vision for Mozilla 2 was implemented in 3.5 – the new faster javascript implementation. But the smaller, leaner, more approachable codebase goal? Who knows.
Now it seems they're attempting 'Electrolysis' (the codename for process separation) in parallel to the development of Firefox.next (Gecko 1.9.2), which is already ostensibly being done in parallel to the Mozilla 2 refactoring. Makes you wonder if there's anyone at the wheel.
Here's an essay I wrote about Mozilla's direction back in 2007 when Mozilla 2 was supposed to kick off.
The Rise and Fall of Online Community
This is a pretty ungenerous view to take. First off, the Mozilla community is not confined to geeks on Slashdot who care passionately about things like process separation. The Firefox developer community most certainly does care about its users, but the users don't necessarily know that they want, much less could benefit from, process separation. Like Henry Ford said, "If I had asked people what they wanted, they would have said faster horses." So, Firefox developers delivered what the mass base of users wanted. If anything, you might fault them for being overly user-driven. We can see this in their focus on adding new features, instead of leaving the trivial features as extensions and focusing on performance, standards implementation, and technical features like process separation.
The Rise and Fall of Online Community
No commercial program on earth takes advantage of more than two cores...
What? Yes, even some of the "high-end drafting" programs do, every single 3D Modeling and/or Drafting application I have, can use 1, 2, or 4 (and likely upwards, but the highest core/CPU PC I have is 4) as they see fit.
Operating Systems are a "commercial program", and most of them can handle 8, 16, 32 or more processors.
If you have information as to otherwise, I'd be highly interested.
The Firefox developer community cares a lot for its users ... compared to the Thunderbird developer community.
Red to red, black to black. Switch it on, but stand well back.
They had to chance a code base from around 5+ years only because they didn't things right 5+ years ago. Remember, back then they were doing a complete code rewrite anyway.
Actually it was more like 10 years ago :/
And you're right -- Internet Explorer 4 had a multiprocess model (one process per window), but Mozilla insisted on having everything running in the same process, even the frickin mail client.
A lot of people questioned this at the time, but the response was "That's the way Netscape Communicator 4 does it and everyone loves Netscape 4".
Business. Numbers. Money. People. Computer World.
It's not a question of multi-core architecture. No commercial program on earth takes advantage of more than two cores, not even the high-end drafting programs on mirrored quad Xeons.
That is a ridiculously untrue statement. Oracle's database certainly uses more than two cores (yes, even the Windows version). A number of engineering and 3D/rendering packages I'm aware of can use more than two cores.
Advice: on VPS providers
OK I'm a user, and I want a browser where the UI doesn't lag when pages are loading. I also want a browser that doesn't completely freeze when a Java applet launches or PDF file opens. I would also like a browser where I don't have to restart the whole thing when Flash gets borked and refuses to play youtube videos.
Point being there's a lot of user-visible issues and longstanding complaints which are addressed by this. Furthermore, the incumbent browser (IE) doesn't have any of these issues.
(And "Use Adblock and stop using Java/Flash/PDF" is a workaround, not a real solution.)
Business. Numbers. Money. People. Computer World.
Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all. Why not just have rendering worker threads? Have I missed something?
Er. This is an argument which applies to high-volume servers that handle hundreds/thousands of requests per second. Windows' process model is not so heavy-weight that you notice it opening a new browser tab once every few minutes.
Business. Numbers. Money. People. Computer World.
Ask your admins to change the proxy PAC to not using the isInNet function, as this
requires the DNS to check if every domain/hostname exists before deciding what proxy
to use... isnt easy to solve...
i work around with this:
if ( shExpMatch(url, "*127.0.0*") ||
shExpMatch(url, "*192.168.*") ||
shExpMatch(url, "*10.15.*") ||
shExpMatch(url, "*10.16.*") ||
shExpMatch(url, "*10.17.*")
){ if ( isInNet(host, "127.0.0.0", "255.0.0.0") ||
isInNet(host, "192.168.0.0", "255.255.0.0") ||
isInNet(host, "10.15.0.0", "255.255.0.0") ||
isInNet(host, "10.16.0.0", "255.255.0.0") ||
isInNet(host, "10.17.0.0", "255.255.0.0")
) { return "DIRECT"; }
else { return "PROXY 192.168.1.10:3128"; }
}
this way it just use the "bad" function if there is a IP in the URL...
all rest, its defined using domains/hostnames, no need for the isInNet
good luck
Higuita
Lazy bastards. I mean, how hard is it to change what is apparently that one really trivial-to-find call in their code to useProcessSeparationOhAndIAlsoWantAPony(true)? Took them long enough...
The hard part wasn't the process separation, it was the pony.
Finally, apps are getting more multi-CPU focused. Very cool. All of us with multi processor systems thank you.
I want to delete my account but Slashdot doesn't allow it.
> First off, the Mozilla community is not confined to geeks on Slashdot who care passionately about things like process separation. The Firefox developer community most certainly does care about its users, but the users don't necessarily know that they want, much less could benefit from, process separation.
That's the same group of developers who wilfully ignore repeated ordinary user requests to give them an option to accept duplicate certificates, even after some big red security warning. To make things worse, it doesn't even bother to display which certificate and which CA are in violation so the user can delete them. On IE, you can click "Continue anyway" to bypass the self-issued certificate duplication and log on to your router, for example.
Their response: it's the fault of your router company.
This is ridiculous. The Mozilla devs definitely think they know better than the users.
Note that if it were just a performance thing, they could have gone multithreaded instead. This would probably get even better performance.
Firefox is already multithreaded (if it weren't the UI would freeze during downloading, rendering, etc).
It amazes me how many people here on slashdot don't understand the differences and distinctions of multi-process vs. multi-threaded.
Similes are like metaphors
Since everything crashes the JVM.
Write your representatives! Repeal the 2nd Law of Thermodynamics!
I don't know. When I'm looking at a list of bugs and features requests longer then a book, I tend to be pretty picky about which features I implement as well. Having separate processes for each page is great, but you still have to prioritize. Especially when you have the choice between a handful of user-visible features or a not-so-visible feature that none of your competitors had as well. Remember, developers are a limited resource.
I'm really surprised that Microsoft hasn't advertised such a major technological advantage over Firefox in any of their advertising media.
Have they ever advertised against Firefox? I'd be surprised if they did. To compare oneself to a rival is to legitimize that rival.
Learn to love Alaska
I remember some browser (Konqueror, is it?) uses a separate NSPluginViewer process to run Flash. It's the best approach because it let me renice the Flash.
Do you notice Flash runs at a lower priority in IE? (Try running into a busy Flash page and scroll up and down - you'll see the Flash applet slowing down but the UI scrolling of the browser is still responsive.
Not so in Firefox. Hope they'll finally get it right.
The problem now is it will take at least 3 years to stabilize. Who wants to be first to test this thing? multiprocessing code needs to be planned from the beginning or else it will take TONS of effort to rewrite. I bet this destabilizes everything for ages to come...
One problem we have is that we want to open many of the same applications more than once. Imagine wanting to login to slashdot with two different logins.
Right now in IE and Firefox each tab shares the same cookie space. So when you login with one tab you'll notice the cookie in the other tab getting "overwritten".
Now with multiple processes is this the case. When one tab "open another window" resutling in another tab are these two tabs in the same processes sharing cookies and the like?
The browser is general is a horrilbe state machine. It would be nice if Javascript would support some form of lighter weight cookie that could be access between page loads.
Uhm, I've written plenty of single threaded apps that can give the appearance of being multithreaded.
All it has to do is use non-blocking calls and make regular UI updates to make sure the user isn't aware of the single-threaded nature.
It takes effort, but its far from a requirement, and in many cases is far easier than writing proper thread safe multithreaded applications considering in almost every toolkit out there there is only one thread that handles ALL UI in an application.
You know that Google Chrome window you see, with all those tabs in it, and all the processes controlling them. Guess what, the GUI you see runs in a single thread, fed by a bunch of backend processes with some re-parented windows.
It amazes me how people post on slashdot as if they know everything about programming when they really don't have a clue.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
My firefox actually does freeze while rendering a page. It's mostly obvious on my slower linux box. Not that I'm disputing its multi-threaded nature, it clearly *can* do two things at once, just not the things I need it to do (like load slashdot while allowing me to click back to another tab).
A lot of people questioned this at the time, but the response was "That's the way Netscape Communicator 4 does it and everyone loves Netscape 4".
I've heard a lot of words used with Netscape 4. I can confidently say "loved" was never one of them.
http://www.microsoft.com/windows/internet-explorer/get-the-facts/browser-comparison.aspx
That link is the only thing I've seen, IE8-wise, comparing it to other browsers. But generally IE doesn't get advertised at all-- I haven't seen an IE ad in ages. (Of course, I don't watch TV, so there's a whole world of advertising I get no exposure to.)
Comment of the year
So yes, flash can lock up a thread, and since a large amount of firefox users intentionally block flash, its not actually that pressing of a need.
This is based on a particular set of assumption - that all Flash is bad, that all Flash is undesired, and that only unwanted Flash is causing problems. And I'm also not sure what percentage of Flashblock FF users have installed, or how it's configured.
In the days of YouTube, Hulu, etc., Flash content is very much desired, and depending on a plugin to fix a fundamental design weakness in the browser is not the best idea I've heard of.
Just because it's not a pressing need for YOU, doesn't mean it's not a pressing need.
I guess at least you can always talk out your ass now that everyone else is doing it and pretend you knew this all along. Obviously it was your idea.
I've actually been talking about this for _years_, here and elsewhere, along with many others, under this undername. If you wish to waste your time, check up on it. But you should do that before you accuse me of jumping on some bandwagon with no proof.
> But the smaller, leaner, more approachable codebase goal?
Somewhat. It doesn't get blogged about much, and when it's blogged about the press doesn't pick it up because nitty-gritty arch work is boring. But there have in fact been significant simplifications to all sorts of stuff in the meantime...
The really ambitious "break compat and all" plan for Mozilla2 seems to have been somewhat abandoned for now, though.
A non-blocking call implies multi-threaded design, genius.
It really doesn't. Maybe a similar design to a multithreaded app, but more accurately an event model, not a thread model. It's cooperative multitasking, which means it won't hit multiple processors, and generally won't have anywhere near the same kind of concurrency issues.
I suppose you could make the argument that the OS is doing the threading for you, or that it's a kind of green threads, but at that point, it's both a semantic argument, and it's losing any semblance of meaning of "threaded".
Don't thank God, thank a doctor!
Let me guess, you are running on ff on ext3? Upgrade to ext4 (or run windows or mac) and the problem is not there.
The idea is/was to do a large scale cleanup and refactoring.
And it's getting done in pieces. Mozilla developers wrote a string of tools (Elsa, Oink, TreeHydra, DeHydra) to analyze the codebase, all open source and some contributing to GCC's rearchitecture to better support plug-ins Developers can then pick specific cleanups and refactoring and identify exactly what code is affected and even do rewrites, though these go through code review. This happens steadily.
DeCOMtamination proceeds. In each release a few major internal rewrites get in, like the switch to thebes on Cairo and the HTML reflow changes; upcoming is Combined nsImage* & gfxImageFrame and the HTML5 parser.
There's no need to wonder when all the development takes place in the open. Pay attention or don't style yourself as an armchair expert.
=S
What amazes me the most is how practically everybody looks at this from the "when it crashes" point of view, when to me personally the biggest advantage to all of this is that one can actually have 40+ tabs open and having the system need Only swap in the Current Tab instead of every single tab all at once after an extended period of browser inactivity (likely causing the system to swap out the currently single browser process).
I know people will say RAM is cheap and all that ... but still why should the system worry about swapping back in all 40+ open tabs when i am really only interested in the currently active one. Let it worry about swapping in another when i want it.
> I've heard a lot of words used with Netscape 4.
> I can confidently say "loved" was never one of them.
Whippersnapper. You say "never" because you're too young to remember.
When Navigator 4.0 was first out, and people were comparing it to version 3, the new version was a huge improvement. It wasn't until it'd been out for several years and the most significant update was the Communicator suite (which used more memory and didn't improve the browsing experience at all) that the cheers started to turn into groans, and then when version 5 didn't come out, and didn't come out, and didn't come out, the groans eventually turned to outright boos and hisses. But that was years later.
Heck, I remember when people loved Netscape 2. Of course, back then the other main option was NCSA Mosaic. Or gopher.
Do I want to use any of that stuff *now*? Not on your life. But I loved Navigator 4.08 well enough in its day.
Cut that out, or I will ship you to Norilsk in a box.