Live data from Hacker News

Electrolysis – run web content in a separate process from Firefox

wiki.mozilla.org

61–70 of 107 posts

Re: Electrolysis – run web content in a separate process from Firefox

#61
post #60

Earlier quoted context omitted.

Because, as I said earlier, "you're going to feel it." If your tabs are allocating in the same process address space as each other, accessing your current tab's data is likely to cause swapping. The key point is that electrolysis and chromium-based browsers can page inactive tabs "without affecting performance of the current tab."

This isn't really intuitive, though. When you switch to a tab, either you page in that tab's memory for the current process. Or you page in that tab's process and memory. That is, by going to a "per process" approach, the amount of memory that gets paged in almost certainly went up. No?

The amount of memory that gets paged in went up, but the whole point is that you never have to page any of the current tab's memory while you're using it, unlike with the monolithic 1 GB Firefox process today.

I feel like I must not have been clear earlier because I have made just a single point, and both of you are discussing things not related to that point. Let me try one more time: it's all about performance of the current tab.

Re: Electrolysis – run web content in a separate process from Firefox

#62
I was wondering about the benefits of this. Supposedly having tabs in different processes should improve performance of the browser in general, as slow running scripts in one tab process won't slow down the main UI process. I have come across this problem before, including the whole browser freezing from some slow JS. But does this need to be done with separate processes? Surely running tabs in a different thread to the UI should solve this issue too?

I'm a bit concerned about the effect this could have on RAM usage and plugin compatibility - the linked wiki page already lists two plugins that I can't live without (NoScript and Tree Style Tabs) as being incompatible. Hopefully that will be fixed before this becomes default in a release.

Re: Electrolysis – run web content in a separate process from Firefox

#63
post #60

Earlier quoted context omitted.

This isn't really intuitive, though. When you switch to a tab, either you page in that tab's memory for the current process. Or you page in that tab's process and memory. That is, by going to a "per process" approach, the amount of memory that gets paged in almost certainly went up. No?

The amount of memory that gets paged in went up, but the whole point is that you never have to page any of the current tab's memory while you're using it, unlike with the monolithic 1 GB Firefox process today. I feel like I must not have been clear earlier because I have made just a single point, and both of you are discussing things not related to that point. Let me try one more time: it's all about performance of t…

Right, and the counter point is that this should not help there. If the other tabs are idle, than they are idle whether in process or not. If they are all cpu bound doing stuff, then your machine is again in trouble, current process or not. If they are all constantly thrashing in resources, you are still in trouble.

Why would you think the current monolithic would page out a tab that was actively being used? Why would this not also happen in the "per process" approach?

That is, how would this specifically help? If you are actively using the memory for the current tab, because it is the current tab, why would it be swapped out under the monolithic case where it would not in the per process case?

I'm perfectly willing to accept there is a scenario I am not considering. I just don't see it, right off.

Re: Electrolysis – run web content in a separate process from Firefox

#64
post #62

I was wondering about the benefits of this. Supposedly having tabs in different processes should improve performance of the browser in general, as slow running scripts in one tab process won't slow down the main UI process. I have come across this problem before, including the whole browser freezing from some slow JS. But does this need to be done with separate processes? Surely running tabs in a different thread to…

Part of it is probably that browsers use so much shared global data that it is easier to just make another process. There are also fault isolation and security benefits you get from splitting the web content into a process that can have a tighter sandbox policy.

Re: Electrolysis – run web content in a separate process from Firefox

#65
I'm really glad Mozilla has been working on this. A lot of comments here talk about UI responsiveness being the key benefit, but another huge win is that it limits the damage a browser zero-day can do. With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces.

This of course assumes a compromised tab can't go on to compromise the browser kernel (i.e. the process that manages tabs and shared tab state) or trick the kernel into giving it unauthorized data from other tabs. However, formally verifying that a kernel implementation prevents this is feasible in practice [1].

[1] http://goto.ucsd.edu/quark/

Re: Electrolysis – run web content in a separate process from Firefox

#66
post #11

Earlier quoted context omitted.

I think performance is often overblown on this as well. However, I don't think the overhead from task switching will really enter into it. If you have hundreds of tabs open that are trying to do work, that is work that was having to be done regardless. Meaning they would already be thrashing. Now, that will just be in a different way. Otherwise, if you are idling most of those processes, they should be the same as be…

Firefox: Averages ~5MB/tab (200 tabs, 1GB memory) Chrome: Anywhere from 50MB/tab up. A much better performance fix would be to suspend javascript execution on tabs that aren't visible.

Talking about "memory usage per tab" doesn't make much sense unless you talk about what's in the tabs. It's rather like talking about "memory usage per application" on your desktop and not mentioning whether the application is ed or OpenOffice.

Suspending JS execution in invisible tabs seems highly unlikely to be web-compatible; you wouldn't want YouTube or Spotify to stop playing just because you focused a different tab. On the other hand, with technologies like requestAnimationFrame, we can make it possible for well designed applications to work well when in the background.

Re: Electrolysis – run web content in a separate process from Firefox

#67
post #65

I'm really glad Mozilla has been working on this. A lot of comments here talk about UI responsiveness being the key benefit, but another huge win is that it limits the damage a browser zero-day can do. With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces. This of course assumes a compromised tab can't go on to compr…

> With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces.

... assuming those tabs are cross-origin.

> This of course assumes a compromised tab can't go on to compromise the browser kernel

Also assumes that a compromised tab can't go on to compromise the OS kernel.

Re: Electrolysis – run web content in a separate process from Firefox

#68
post #60

Earlier quoted context omitted.

This isn't really intuitive, though. When you switch to a tab, either you page in that tab's memory for the current process. Or you page in that tab's process and memory. That is, by going to a "per process" approach, the amount of memory that gets paged in almost certainly went up. No?

The amount of memory that gets paged in went up, but the whole point is that you never have to page any of the current tab's memory while you're using it, unlike with the monolithic 1 GB Firefox process today. I feel like I must not have been clear earlier because I have made just a single point, and both of you are discussing things not related to that point. Let me try one more time: it's all about performance of t…

[deleted]

Re: Electrolysis – run web content in a separate process from Firefox

#69
post #60

Earlier quoted context omitted.

This isn't really intuitive, though. When you switch to a tab, either you page in that tab's memory for the current process. Or you page in that tab's process and memory. That is, by going to a "per process" approach, the amount of memory that gets paged in almost certainly went up. No?

The amount of memory that gets paged in went up, but the whole point is that you never have to page any of the current tab's memory while you're using it, unlike with the monolithic 1 GB Firefox process today. I feel like I must not have been clear earlier because I have made just a single point, and both of you are discussing things not related to that point. Let me try one more time: it's all about performance of t…

I still don't see the scenario you're describing, though. Let's say you have two tabs open, A and B. Then some set of pages will have memory for A, and some set will have memory for B. If you're not using A, then the operating system will notice that those pages have not been used in a while and if under memory pressure it will page them out. This won't affect pages with memory for B.

The only issue would be if most of the memory allocations are under your system's page size (typically 4096 bytes) and distributed randomly, so that a lot of pages have data structures associated with multiple different tabs. But I think that's unlikely, and even if it is true, couldn't it be resolved by making your allocation strategy tab-aware (e.g., by giving each tab its own malloc arena, which would be way simpler than splitting the browser into multiple processes).

Am I missing something here?

Re: Electrolysis – run web content in a separate process from Firefox

#70
post #62

I was wondering about the benefits of this. Supposedly having tabs in different processes should improve performance of the browser in general, as slow running scripts in one tab process won't slow down the main UI process. I have come across this problem before, including the whole browser freezing from some slow JS. But does this need to be done with separate processes? Surely running tabs in a different thread to…

Another argument for running in multiple-processes as opposed to multiple-threads is that a crashing thread will bring down the whole browser.

A crashing content process, on the other hand, can just "crash" the tab, and show an interface for reviving that tab.

Post reply on HN