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.
What took so long?
Wolde you bothe eate your cake, and have your cake?
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.
...to see Firefox desperately jumping on the multithread bandwagon. Yes, of course restarting your browser once about every month is a terrible pain in the butt. Takes a long time too! I'm thinking: they didn't design for this from the start, so implementing it now will not be worth the headaches caused by unforseen issues.
Now I'll know that before updating Firefox I have to carefully read the "what's new in version x.y" part.
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. If the browser is stable, what benefit do multi-processes have? Multiple Firefox processes seems like unnecessary overhead. 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?
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?
XML is a known as a key material required to create SMD: Software of Mass Destruction
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.
Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.
Chrome does it on Windows and it's okay.
Why not just have rendering worker threads?
There are two benefits to switching to this. First, it will become more responsive as one tab is much less likely able to eat CPU for a while and delay others (something that happens to me enough I have to restart Firefox for that reason every day or two). But the second reason is that if one tab causes a crashing bug to manifest, it is much harder to bring down the whole browser, and instead it just brings down that tab.
Threading gives you the first benefit, but not the second. Processes give you both.
I'm not sure how important the second reason is, but I do get crashes from time to time because of Flash.
Security
Speed ----------- You are here.
Security ----------- The rest of the world is here.
Speed
Need to catch up mate. We'll be getting rid of virtual machines next too.
Deleted
The biggest problem nowadays isn't memory leaks but rather fragmentation.
Of course, the multiprocess architecture helps with that too.
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.
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.
That doesn't solve the stability problem. If one of those worker threads does something naughty, the whole process is going down.
Although process creation time on Windows is slow compared to other OSes its more than fast enough for spawning a process per tab. Chrome and IE8 have already proved this in the real world.
Before I dumped Firefox months ago I would have to quit the piece of shit browser 2 to 3 times a day to clear out the crud that gets left behind with every minute of use.
The only people pathetic enough to put up with such a piece of junk app are people who still think they are being cool and impressing others with "I'm kewl, I use Firefox, not IE!"
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.
So will this also run those forks with niceness values that wont cause flash to make my Ubuntu machine unable to register mouse movements or keystrokes (effectively leaving a reboot as the only option) for poorly written flash applications?
The Microsoft folks don't seem concerned about this, at least not concerned enough to implement it in IE.
It's implemented in IE8.
Process creation is much cheaper under Windows than it used to be.
And one crashed thread takes out all the threads, resulting in--gasp!--the current situation, as Firefox's tabs are nominally multithreaded.
Process segmentation is the only way to retrofit that bad codebase into actually some sort of working order when compared to IE8 and Chrome. It should also help their astonishing memory leaks too.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
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.
Are you kidding? This is the Firefox dev team. Of course they won't. They'll say it's impossible, and call you an idiot for even thinking of suggesting something like that. Not until someone Microsoft or Google does it, will they feel any need to implement something so useful.
Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.
Yeah, cuz multi-process Chrome on Windows is such a piece of shit?
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.
I've been doing this exact same work since the mid-90's. Anytime you have a processor intensive or I/O task in a Windows environment, it should be moved off of the primary thread. Even if the process is being run on a single core processor the UI will still be responsive (albeit possibly laggy) while the I/O and calculation is running.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
The Microsoft folks don't seem concerned about this, at least not concerned enough to implement it in IE.
It's implemented in IE8.
You mean render threads right?
XML is a known as a key material required to create SMD: Software of Mass Destruction
Get the Java dick out of your ass please.
Hey, leave the other dude alone and wait for your turn.
Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.
Yeah, cuz multi-process Chrome on Windows is such a piece of shit?
This is purely anecdotal... but as far as I can tell for my daily usage Chrome is no faster than Firefox 3.5 with adblock. (Adblock ftw)
XML is a known as a key material required to create SMD: Software of Mass Destruction
This is excellent and ties directly into a thread in a previous posting regarding the isolation/sandboxing of the browser. Apart from using the multiple processes to guard against a crash taking down the entire browser, they should employ all of the capabilities that the OS provides to isolate the child processes into as tight of a constrained context as possible. That will help mitigate successful exploits of vulnerabilities of the renderer and dependent libraries.
Furthermore, if Mozilla is serious about joining this party, I seriously think that Microsoft, Google and Mozilla need to sit down together and come up with a recommendation for writing plug-ins that can be hosted safely out of process. That would increase the reliability and security of the browser by preventing a failing plug-in from taking the browser with it, or a vulnerability in a plug-in from being able to exploit the system outside of the sandbox.
Whether or not Chrome is adopted and used as a browser, the project was a success in spurring needed innovation.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
This is purely anecdotal... but as far as I can tell for my daily usage Chrome is no faster than Firefox 3.5 with adblock. (Adblock ftw)
Anecdotal is the best evidence in this case. I've run Chrome with over 90 tabs, and it kept on chugging. And what does speed have to do with a browser being multi-process? The benefits are security and reliability, with the downside being memory usage.
Or the multi-process Explorer.exe on Windows 7 :)
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.
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?
One of the main reason's threads are more lightweight than processes is because they share an address space (so it's cheaper to switch between threads - you don't need to reload page tables), but the downside of that is that one thread can corrupt another. Processes don't share memory hence they are better isolated from each other.
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 Google's Chrome humiliated the Firefox developers.
Then Microsoft's IE 8 kicked Firefox developers in the nuts.
I'm really surprised that Microsoft hasn't advertised such a major technological advantage over Firefox in any of their advertising media.
When I hear multi-process browsing the first thought is why? Don't our browsers already use enough memory within a single instance of itself?
What is wrong with a multi-threaded application that can use multiple cores simultaneously?
With multi-processor you end up with a more complex memory model (domain sockets, shared memory..etc for inter-process communication) This can only increase the global complexity and chance for bugs within the system.
You end up with duplication of the same core code in memory with no reduction of synchronization complexity which necessairly means increased memory usage.
If there are structural problems with the browser such that it freezes
or is not reliable I would rather see these problems corrected. If the code is that bad then I don't think its unreasonable to also assume its also insecure and expliotable.
Now that I'm here I also want to see the dizzying array of plugins go away - they are a reliability and security nightmare.
Profile data cannot be shared by multiple running instances.
Firefox is already multi-threaded. Single process, multi-threaded. Any one thread can crash the entire process. One process cannot crash another process, at least not directly.
Similes are like metaphors
Does this mean I can have five different Flash players hijacking my CPUs at once?
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.
This is purely anecdotal... but as far as I can tell for my daily usage Chrome is no faster than Firefox 3.5 with adblock. (Adblock ftw)
Anecdotal is the best evidence in this case. I've run Chrome with over 90 tabs, and it kept on chugging. And what does speed have to do with a browser being multi-process? The benefits are security and reliability, with the downside being memory usage.
Actually... in the extreme usage scenario there is a memory advantage to multi-processing as well: closing the process is guaranteed to free the allocated (unshared) process memory. Poor man's garbage collection.
XML is a known as a key material required to create SMD: Software of Mass Destruction
Anecdotal is the best evidence in this case. I've run Chrome with over 90 tabs, and it kept on chugging.
I've done the same with Opera. I've tried it for fun in IE and Firefox, and it wasn't pretty (or successful).
Learn to love Alaska
ting HAIRS... so why not call it....
"HYDROLYSIS"?
But, wait, isn't electrolysis a way to remove hair? Well, if that's not good or damaging enough, call it...
"fibrin(ogen)olytic"....
Oh, what the hell...
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Forking a process on unix-like systems if fairly lightweight but for Windows this will not scale well at all.
How many tens of thousands of times per second do you need to open a new browser tab?
Dewey, what part of this looks like authorities should be involved?
That you'll never find FF developers admitting doing ANYTHING wrong on the Bugzilla forums.
Anything. Do you believe in flawless designs? I don't - but arrogant developers apparently exist.
When I ctrl+alt+del it, will it show as many different processes as there are tabs + main process?
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.
Splitting applications into multiple processes... it's like the 1980's all over again.
Well, multiprocess programs do use *more* memory. Google Chrome's memory handling is terrible.
Partly because webkit leaks badly, so to release memory, they have to kill a tab process, partly because firing up new
processes does require some memory.
http://dotnetperls.com/chrome-memory
I imagine that's why they call this Electrolysis...it's a hairy problem now that it's been ignored for so long.
I was thinking more along the lines of "With Electrolysis, surfing pr0n will be better than ever." But your theory sounds better.
It's really good to see this sort of thing happening, no matter what feature it is, and what browser pioneered it.
Today, we (finally!) have a fairly competitive browser market, and here are the results of it: as soon as one browser adds a feature that is genuinely good, others race to implement it as well, sometimes developing it further in the process. Even IE had something to bring to the table (process-per-tab first appeared in public IE8 betas).
Competition is good. More competition is better. Bring it on.
Great, it can now eat all the cores on my computer like it eats all the ram.
Living in Chile
Would be nice if the firefox process that does the heavy-lifting could change it's uid to something other than the person running firefox; although not a perfect solution, it could minimize data loss due to web-based compromise if process id does not have access to $HOME.
boycott slashdot February 10th - 17th check out: altSlashdot.org
Kindly stop spreading informative and correct information about Windows' process model. You are interfering with my Slashdot experience. Creating a process in UNIX is quicker than in Windows, hence, UNIX is superior. What is there to not understand?
Making software more robust by adding complexity to it (multithreading) is by no means a winning formula - how often does a "rogue" tab bring down the others, vs. the number of race conditions and deadlocks users will experience with the new design? Only time will tell, so forking for a while and trying it seems the perfect solution.
Normally us opera fanboys get to respond to every "firefox has amazing new feature X!" post with "yeah, but opera's had that for years"; but in this case it seems firefox might end up having a feature released first -- how can this be happening? /o\
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
I meant to say that they weren't concerned enough to implement IE8's architecture using threads, as opposed to processes.
Process per tab made its debut in IE8, not Chrome.
A thread approach has most of the same difficulties as a process approach without some of the (security, stability) benefits. Put another way, if one thread crashes, you lose.
It can also be _harder_ to write well-isolated shared-nothing code with the thread approach, since threads make it so easy to share state... and then you start running into synchronization, deadlock, and locking overhead issues.
At least if you're using the WebSphere AppServer it does.
Background: OutOfMemory is the single most useless exception of [b]any[/b] VM. Once it's out of memory there is almost nothing you can do, short of aborting the process to let the system reclaim the memory. Much better to design your processes to fail gracefully (i.e. atomically/transactionally). That's why Erlang is so popular amongst people who want 99.999% uptime.
I'm reallly impressed with Chrome's speed and stability, but have to stick to Firefox for its addons. To make me happy only one of the two things should happen:
1. Chrome gets addons more like Firefox's
2. Firefox becomes more like Chrome
And thank you, Google, for contributing to the world your refreshing ideas and code.
"Bloat" is a myth perpetuated by a certian sect of technical people that seem to think that anything that isn't done in assembly and can be sqeezed into 640kb of memory is "bloat". Good sir, nobody cares about "bloat". We don't have tape drives and ram isn't $400 a meg. Bloat is a myth.
There is no such thing as "bloat". There is only applications whos feature set is poorly organized. The more features you add, the more attention you have to give to how said features are accessed and how they relate to the goals and tasks the user is trying to accomplish at any time.
Of course they use more memory--you have duplicate code pages in different processes--but it's a fairly small amount.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
So your single-core cpu is only ever capable of running a single process?
I run MS-DOS, you insensitive clod!
http://cltracker.net -- powerful craigslist multi-city search
About time you upgrade there pal. You people make our lives a living hell.
Anecdotal is the best evidence in this case. I've run Chrome with over 90 tabs, and it kept on chugging. I've done the same with Opera. I've tried it for fun in IE and Firefox, and it wasn't pretty (or successful).
I've got over 100 tabs open in firefox 3.5 now... Works On My Machine (TM)
XML is a known as a key material required to create SMD: Software of Mass Destruction
"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"
No - they'll fix MOST (or even SOME) of the things that break in the process.
This is how Mozilla produces a Firefox that crashes and takes down the whole KWin system.
This is how Mozilla produces a bug-ridden browser.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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.
That was super informative, thanks!
The Rise and Fall of Online Community
They mean the java.lang.OutOfMemoryError I am sure
In a single process environment all calls are blocking. So the fact that you use the term non-blocking suggest that you are implicit making use of more than one *process*
It amazes me...
In a single process and single threaded environment all calls are non-blocking (I know this is pedantic, as almost any system call will involve another process).
Adobe has managed to get Flash to be the de facto standard for most web pages on the Internet, yet I would not have needed Chrome or other browser with this process separation if it wasn't for Flash. It crashes my browser, and as a Mac OS X user, it slows down not only my web browser, but my whole machine almost to a halt.
I so wish that either Apple do a deal with Adobe so that they get source code and can fix it themselves, or that Apple secretly are writing a clone that will be part of Snow Leopard.
Hmm.... I wonder how many watt/h of energy Flash is wasting in total over the world, CPU's going up to max when could be in low power mode, forcing us to buy a faster CPU with multi cores just to browse the web. I think Adobe should pay some sort of energy tax ;)
Or, as I imagine they don't make money from the flash plugin, make it OpenSource so that others can help them fix it.
Comment removed based on user account deletion
This is a wonderful opinion. The things mentioned are unanimous and needs to be appreciated by everyone.
Restaurant Jobs
Of course they use more memory--you have duplicate code pages in different processes
Uh, no you don't. Linux has copy-on-write for forked processes. Of course, the same can't be said for other OSes (Solaris, for example).
I was thinking Windows, but apparently NT does have copy-on-write. My bad.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Including the mail app in the same process was a bit daffy.
I can't agree it's much better to use a multiprocess model so that my 4 core CPU grinds to a crawl when I open up all the tabs I use (40-50 average). Chrome absolutely crawls. Maybe they need to refine the idea a little.
IE had to have a multi-process model because it crashed so much and was tied to the OS. Even so a browser problem totally trashed the system as often as not.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Seriously.
Hmm.... I wonder how many watt/h of energy Flash is wasting in total over the world, CPU's going up to max when could be in low power mode, forcing us to buy a faster CPU with multi cores just to browse the web. I think Adobe should pay some sort of energy tax ;)
And you can take the ;) off the end of the sentence. They really do measurably raise my electric bill.