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.
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).
You get it. The one thing you're missing is that application-aware allocation is hard and something that Firefox engineers continuously have to work on (http://blog.pavlov.net/2007/11/10/memory-fragmentation/), even as they add new features and performance caches. The electrolysis/chromium solution makes the problem disappear entirely (along with some security problems) without any possibility of regression.
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.
Because the tab you're using has barfed its data all over the heap, so you can't keep all its data paged into main memory. Its data is mixed together with the other tabs' data.
At face value, I don't see why this should necessarily be the case. That is, why would a tab "barf its data all over the heap?" More directly, why couldn't, as the sibling said, this have been addressed with a different allocation mechanism.
I'm assuming this has come up a fair bit. Any good links to read up on this?
