Hacker News Reader

Comment by pilif | Hacker News Reader

while it's certainly not a very good example of good network citizenship to send 2 megs of NULL bytes, I think Opera shouldn't be crashing here. The fact that it does points to a bug in the code that might potentially be exploitable beyond the simple denial of service which it already is.

AFAIK Opera still runs all tabs in one shared process, so spamming one tab with 2MB of NULL will cause the whole browser (and with it all other tabs) to crash.

View on HN

They said so in the post: “We should fix that”.

There are other browsers out there that have the same problem regarding tabs, namely Firefox. A misbehaving tab causes the whole browser to stall and you can't even kill that single tab. So Opera isn't alone in that regard.

I thought Firefox had already isolated tab processes a couple releases ago?

They isolated plugins (like Flash), but the project for tab process - called Electrolysis - was put on hold last year.

http://lawrencemandel.com/2011/11/15/update-on-multi-process...

Nope. The major fix that they did was to eliminate memory leaks in extensions when the user closes a tab.

no, there is still no meaningful isolation in that regard.

Right now I have 101 tabs running, and only 6 cores in my CPU. Do you know how much context switching costs in terms of performance? Do you know what the overhead would be if I were using Chrome?

So spare me, please. When general purpose computing moves to GPUs then we'll revisit the idea of "one tab per process". Until then, out of "Chrome, many tabs, performance", pick any two, drop the other.

The context switch itself is almost trivial at that scale -- a couple hundred ns per switch, with the occurrence interval in the 10s-100s of milliseconds, depending on the CPU scheduler. The part that hurts is all the cache invalidation. Unless you're actually swapping. Then you're really hosed.

Well, that and any particularly nasty plugins (cough flash cough) that don't like many instances at once.

Which OS are you running? I have yet to see chrome on linux have any hiccups on as many tabs as I throw at it. The only time I've seen hiccups are when the X server's busy on something else or I'm short on memory.

If you're on another OS, perhaps chrome's suffering b/c it can't share GDI resources (or mac's equiv) across tabs? I'm assuming it can't, as each tab's got a different process ID.

Context switching isn't that big a deal, it's actually pretty good for responsiveness since everything isn't being serialised through a single thread. Compare/contrast animgifs on a busy Opera vs a busy Chrome - Opera will regularly freeze momentarily, presumably because of stop-the-world GC.

The bigger problem is having that many tabs open without burning through enormous amounts of memory. Chrome's at least 10x less memory-efficient than Opera in this regard, which isn't great when my Opera sessions regularly run to well over 4GB :)

You are right, your scenario is much more visible nowadays. It's just that I have in mind my old single core CPU and how Chrome managed to grind my system to a halt with only a dozen tabs.

Chrome could do that with one process as well as with 100.

> Do you know how much context switching costs in terms of performance?

How much do you think? Most of your 101 tabs should be idle, not active, so my guess would be "not much".

> Most of your 101 tabs should be idle, not active, so my guess would be "not much".

Keep open in the background a few js-intensive websites (e.g. gmail, twitter) and your tabs will be flickering like the proverbial Christmas tree. Depending on your hardware, the paradigm difference can be very noticeable (also, have fun on a laptop's battery).

But Chrome - and any sensible browser, really - will scale down JS execution on pages not in the foreground; you can see this in for example Piecon (http://lipka.github.com/piecon/), which will only update the favicon in your background tab bar at half the speed (if that).

I believe that Chrome caps the number of processes that it uses, so you wouldn't actually be using 101 processes. I think it caps at something like 8, or did when Chrome first came out.

"pgrep Chrome|wc -l" gives me 54 right now with 2 windows open (29 tabs + 2 tabs)

yep, one master, one GPU process.

plus, one per: tab, extension, and plugin.

>>>>Right now I have 101 tabs running

Dude, I get claustrophobic if I have more than 4 or 5 tabs open. Dare I ask why you have 100 tabs open?

Answered the "why" somewhere below, I think you're more concerned about the "how".

Place your tab bar on the left (vertically) and make it wrap to multiple lines (or columns, in this case). I have two columns at the moment, the second one with room for more tabs. Combine this with tab stacking and you have a winner.

You can have your tab bar wrapped to multiple horizontal lines but it's not as efficient given today's widescreen monitors. On lower resolutions (e.g. laptops) it's harder to put as many tabs, but the system is the same and you can still get a decent amount open.

Give it a try, 4-5 tabs is nothing.

That sounds like a personal problem. Your brain can't possibly handle anywhere near the amount of information 101 tabs provides at once, there's no reason to do that.

I use tabs like bookmarks - sites that I might need now or a bit later. I GC them from time to time. Actual bookmarks are used for things like sending a link to myself at home using firefox sync or bookmarking sites I need to visit again and again, like docs sites, the internal bugtracker, etc. I don't open those from the bookmarks menu though, I just type in the awesome bar and firefox always shows bookmarks first, i.e. I use bookmarks as a manual way to bubble up search results in the awesome bar.

I use tabs like this too and I'm not really happy about that, I just haven't found a better alternative yet.

What usually happens is I'll be browsing and find an article/code library/inspiring web design/useful tool that I know I can make use of later in some way, but if I just bookmark it then I'll probably forget it's in there.

I have very organised bookmarks but these only work for sites I visit often and I do use tools like Evernote and Gimmebar but it still doesn't feel right.

Perhaps Mozilla have the answer: https://blog.mozilla.org/ux/2012/10/save-for-later/

I too browse this way, and it's not about processing all the content at once. It's about utilizing the browser's ability to remember things you can't, and establishing a workflow as you move through the tabs.

It's a bad habit (I can't think of a situation when 100 tabs would be necessary) but it's still pain if browser can't handle that.

Often it's just mis-used as a “read later” list.

I have forum threads, stackoverflow tags, manuals, ... opened. Not exactly a read later list, although I do use tabs for that as well. I use bookmarks for things I want to save for later. Usually something I've already read (at least partially) to know it's worth saving. (I know a bookmark folder/tag would be enough)

I always hold at least two digits' worth of tabs open, usually grouped into stacks. For instance, I have a stack of music/radio related tabs (e.g. youtube), several stacks with documentation that I infrequently need, stacks with tabs that I will read sometime later in the week/month/year, stacks related to various issues in the code I am working on, and so on.

I can't be bothered to use bookmarks for these things, having tabs in stacks is much more convenient. If the browser lets me keep a lot of tabs open then I'll abuse this posibility for my personal comfort. If we were to use your philosophy then Chrome should be limited to a certain amount of tabs by design. How about 6, the number of cores in my CPU?

But thank you for the diagnosis dr. Jobs, surely I'm holding the phone the wrong way too. Keep blaming the user.

It's not blaming the user. The user in this case is using the browser in an unintended way. It it therefore the users' own fault if the browser doesn't hold up.

If I want to ride my bike facing the wrong direction, it's not the fault of the designer that I can no longer steer. I could potentially make it work, but would it ever be reasonable for the manufacturer to add another set of handlebars on the back?

As for your comment about Apple claiming the user was holding their phone incorrectly, they did ultimately provide cases right and therefore admitting that enough users were having trouble to merit a change / fix ?

All said, you are using your browser wrong. Sorry to be the one who has to tell you.

That's a poor analogy. The situation of using so many tabs is about making the browser work harder, not in an incorrect manner. So if I was to compare that to riding a bike it would be like pedaling as fast as I could. If the bike couldn't handle it then yes, I would say it was the manufacturers fault.

I was thinking of a fixed gear bike. It can operate in both directions. One direction has handlebars.

Designers shouldn't be expected to support efficiency on the side they didn't put the bars.

Hold on to this mentality, and you will never develop great software.

The fact is the Chrome efficiently runs many tabs. This guy wants an extreme use case to be primarily supported or the browser must suck.

Supporting it would be a waste of developer time. If they run out of ways to make Chrome faster and have nothing better to do then sure, let's deal with this niche problem.

I do something similar. If I am to open too many tabs and don't really need the dev tools, i.e. doing some casual browsing, I go for Opera, or Firefox instead of Chrome. I also go for them when travelling and the battery is scarce.

Context switching costs far less than the time it takes you to press the key to switch between tabs, and is not appreciably more expensive for a process than for a thread.

Cache validation, on the other hand, can be quite expensive. The context switch itself of course less so.

Your point is actually acknowledged by the author of the post.

aside from Chrome, do ANY other browsers handle tabs separately?

Even Chrome reuses processes for child tabs. As far as I remember it is done to allow JavaScript to access child window from parent.

Which, to me, is one of its biggest annoyances. Opening a slew of tabs from a Google Reader page results in very clear resource contention (one of 8 CPUs pegged at 100% and nothing moving, etc).

Internet Explorer has some degree of tab separation. I'm not sure if it's processes or threads, but it can recover a crashed tab.

Internet Explorer uses processes but may opt to pack more than one tab into a single process to reduce system load by too many processes.

Funnily enough it publicly supported isolated tabs before Chrome did (in a beta release of IE8) :-)

I think Chrome does a similar thing, it groups together tabs from the same origin.

Chrome also has a cap on the number of processes. The process grouping per origin is not really intended as an optimization; it's required by JavaScript semantics.

> Internet Explorer uses processes but may opt to pack more than one tab into a single process to reduce system load by too many processes.

What is it about having too many processes that causes extra system load?

It's a rendering engine and JS engine per process, I guess. Those tend to consume memory (as overhead apart from the actual stuff needed for the page), for example.

I'm surprised that's enough to make a meaningful difference.

Keep in mind that IE8 goes back to the Vista days. That was when there were still computers with just 512 MiB of memory (which might be fine with Windows 8 but Vista would chomp on it hungrily). At least this could be a reason.

Every process consumes additional kernel resources for things like memory mappings, data structures for parent/child relationships, etc. There is also likely to be per-process overhead for libraries that allocate and manage global data structures. For example, the HTML parser likely has some global data structures that can be reused between threads but don't get shared between processes.

Every process consumes additional kernel resources for things like memory mappings, data structures for parent/child relationships, etc.

True, but we should be able to assume that that is negligible.

There is also likely to be per-process overhead for libraries that allocate and manage global data structures. For example, the HTML parser likely has some global data structures that can be reused between threads but don't get shared between processes.

That's what somebody else said, too. I'm surprised that's enough to matter, but I guess it must be.

Windows internals are very different than Linux and 32bit DLL files are not SO files. 32bit DLLs are typically relocatable (as opposed to .so files being position independent), which means they are compiled with a with a preferred load address they must be loaded at. If that address is not available at link time, the code must be moved to a different address and jumps must be fixed up to compensate. Because of that, in practice, loaded libraries are often not able to be shared between processes in memory. The reason for this decision is that pic code requires an indirect jump through an offset table which adds extra processing overhead. 64bit Windows is implemented closer to Linux style .so files due to the addition of new pointer relative addressing.

Thanks for the info! Today I learned.

I don't see why we should be able to assume that the kernel's per-process data structures are negligible. Maybe they are, but you'd have to measure it, you can't just assume it.

I've done enough kernel work to feel that it's a safe assumption in general, but that there may be some exceptions.

For example, I wouldn't be completely shocked if somebody said, "We really need to support a particular version of an old OS that had unusually high per-process overhead in some particular corner case."

If anybody knows how much kernel memory a basic process needs in, say, modern-day Linux, please chime in. I tried looking it up, but didn't find it. Probably it's just sizeof(task_struct), which I can't be bothered to check right now, plus a few KB for stack stuff.

If you try to assume something like that is trivial when I accidentaly spawn over 400,000 or more python processes by accidentaly in a spawning loop (guess why I couldn't count them?), you are gonna get a big shock.

Internet Explorer, since version 8, has one process per tab.

AFAIK, IE8 still had one process per Window, not per tab. It changed in IE9.

IE has tab processes and a UI process – the tab processes can handle more than one tab and do so on slower systems.

It's not very hard to crash a browser or browser tab. There's a certain point where all situations can't be reasonably handled by the browser, and it makes more sense to crash when something unexpected happens.

Here's an example I posted a while back of how to crash most major browsers with a link: http://blog.doteight.com/blog/2011/08/24/this-link-will-cras...

* Just checked, it only seems to work with Chrome these days. I guess the other browsers have figured that one out.

If I were opera, I would quietly suck it up. This is more of their own fault. Even if someone sends you 20M of NUL, you should not crash.

Reply on news.ycombinator.com