I'm just reading through the comic and thought I'd jot down a few things I notice as I go. Take them for what they're worth, high-level opinions.
- Browsers single-threaded? Maybe 10 years ago. I routinely have a CPU-heavy JS running in Firefox and it doesn't stop me working in other tabs.
- Threading is hard. Let's go shopping. Or use processes. So now when I have 50 tabs open, it won't just be 50 idle tabs, it will be 50 idle processes all holding on to their resources, not sharing, not pooling. Hmm.
- The majority of sites I view don't have copious amounts of JS running constantly. In response to events, sure. On load, sure. But not sitting there churning away. So a process per tab for pages that are rendered once and executed once seems a little wasteful.
- Browsers eat more memory because of memory fragmentation, eh? Memory management is hard. Let's go shopping and use processes. Or use a compacting memory manager, eh? What year is this?
- Even without GC it's not difficult to use opaque handles instead of pointers so you can juggle memory around as needed. Perhaps this is the over-optimization of the C/C++ crowd still living large. "I can't afford to dereference ONE MORE POINTER to get at my data! I've got to be direct-fucking-to-the-metal!"
- Not particularly looking forward to seeing 50 Chrome processes in my process lists. The ability to see individual pages as processes and kill them separately does sound intriguing; not sure it's worth every damn tab being a process though.
- Fuzz testing for browsers is a great idea. Zed Shaw and I talked about doing something similar for Ruby implementations...a sort of "smart fuzzing" that sends them parsable but random input. I don't know why more testing setups don't fuzz.
- It will be interesting to see V8 versus TraceMonkey. Hopefully my minders will see there's some value in revisiting Rhino and bringing it up to date (it hasn't had any major work done in a long time, and could be a *lot* faster).
- Pattern-based code-generation behind the scenes is also good. Kresten Krab Thorup demonstrated something similar with Ruby on JVM where instance variables (and I think, method dispatch tables) could be promoted to temporary classes with real fields at runtime, making them a lot faster. I've prototyped something similar in JRuby, but until Java 7 it's expensive to generate and load lots of throwaway bytecode.
- Ahh, now they start talking about using better garbage collection technology. Perhaps the folks who decided processes were the only way to efficiently manage cross-tab memory shoulda had a V8?
- Dragging tabs between windows sounds pretty cool. Except that I actually find multiple browser windows to be a nuisance most of the time (and no, not because I can't drag tabs...because I generally browse everything full-screen and would have to search for the right window). Besides, I can drag tabs in Firefox already. I suppose the benefit in Chrome is they wouldn't have to reload. Do I care?
- I just dragged the Chrome comic to another window to test it and then spent 30 seconds trying to figure out where I dragged the Chrome comic. Multiple browser windows = fail.
- I'm glad browser address completion has been made "really compelling" finally.
- Finally someone makes local browser caching smart! I'd say probably 50% of the pages I visit never ever change, like online documentation. I never want to have to go to the net to view them if I don't have to, and if I'm not connected...dammit, just give me what's in the cache!
- On the other hand, there's privacy concerns too. Hopefully I can have full control over what is and is not cached and an easy way to flush it. I can imagine someone borrowing my browser for a moment and stumbling onto a non-public page I've cached.
- Opening an MRU page in a new tab is fine, but I'm almost always using the keyboard to open a tab. Hopefully this isn't going to get in the way of my immediately typing a place to go, which is usually why I open a tab.
- Ahh, there we go, an "incognito tab" for private browsing. Seems like a good way to go.
- Not sure I'm seeing the keyboard angle well-understood here. Hopefully that's not the case. As much as possible, I avoid the mouse, even when browsing. Attention to the keyboard crowd would go a long way, especially in geekier communities. Example: keyboard support in most Google apps is bafflingly arbitrary. Maybe that's a limitation of JS or the "old world" browsers. Maybe not. Still baffling.
- I hope there's going to be support for Java in Chrome. Seems like it would be a big win, since it already can share some data across processes (like the the class libraries), misbehaving applets wouldn't impact the rest of the process (which is admittedly a good case for process-based isolation...maybe use the presence of heavy JS, plugins, applets as the indication to process-isolate?), and I'd wager Google could do a cleaner job of integrating it (without it being intrusive) than other browsers have so far. Plus since plugins are already being offloaded to a separate process, that could be a single JVM kept warm (or separate JVMs, for more memory use but better isolation and sandboxing). Java ought to be one of the best-behaved plugin citizens...done right.
- I wonder how long it will be until Chrome gets Google API updates (like Gears) before the other browsers. I don't buy the "we just want to make the user experience all unicorns and lollipops" thing. There's a business motivation for Chrome. More ad exposure? A first-class deployment for Google APIs so more people write for them so more people use Chrome so ads are easier to channel?
- Ahh yes...we want them to be open standards. Maybe they will, maybe they won't. If they don't...here's where it gets squirrely...it's open source! Anyone can take what they want and put it in their own browser, right? Yeah, you and the other 100 plugins that only work in one type of browser. How quickly do they get gobbled up by others? You do realize it takes some dedicated resources to "take what you want" and maintain it, not to mention keeping it up to date with the original. A commitment to always supporting all browsers seems to be much harder once you've made a monetary commitment to building your own browser. Left hand, meet right hand.
- I won't ask the "why didn't you just help Firefox" question, since it's obvious and there's a million reasons why someone starts a new project. But I will ask why this project to "help all browsers become more powerful" is sprung on the world a day before the beta. There's a desire for exclusivity here or I'll eat my hat. Unicorns and lollipops would have required opening the project months ago, so "all browsers" could benefit from it *as it progressed* and contribute *as it progressed*. Open is not "open once we're ready to beta our product because we think it's nearing completion", it's "we're working on it now and want everyone to benefit from it as we move forward."
And I reserve the right to completely flip any of these opinions after the beta is released this evening...though I probably won't, since I can't run it (Windows only).
Update: I borrowed a friend's Windows machine to give Chrome a 15-minute try. Here's my additional 15-minute thoughts, so take them at face value.
- I hate installers that download additional stuff. When my friend and I first downloaded, we proceeded to walk away from the interwebs for some offline fiddling. Only then did we discover we didn't have the whole thing.
- Love the interface. It's almost too clean. Unfortunately I can guarantee I'd immediately clutter it up with bookmarks I need (want) one-click access to. Such is life. But I like starting from a blank slate first, rather than starting from a cluttered mess.
- Very fast, true to form. It also feels snappier than Firefox, but Firefox isn't known for it's blazing speed. Maybe feels faster than Safari. Of course, young products are always fast.
- Not quite a process per tab. It seems like tabs manually opened and presumably tabs opened from bookmarks do get their own processes. Tabs opened via right-clicking on the link and choosing to open in a new tab stay in-process. That's a reasonable way to reduce process load, since a good portion of the tabs I open are from existing pages like Reader or News. Unfortunately, this also means that a good portion of the tabs I open are not subject to the sandboxing or isolation touted as a key feature of Chrome.
- The developer pages list a Mozilla Java plugin wrapper among the included technologies. Yay! I did not get a chance to try it out (Windows rapidly started to piss me off again).
- I picked a tab at random to forcibly kill and the entire browser disappeared. I guess I picked the right one.
- This is a little worrisome:
All told it's about what I expected. Very clean, very polished, very young. I'm sure a lot of these issues will get shaken out during the beta. I do hope there's a way to turn off a tab-per-process, or I can't see myself ever wanting to run Chrome. I can see myself gathering several dozen Chrome processes in the course of a week. Process isolation for other aspects (like JS or plugins), no worries. I'm looking forward to an OS X version, and from looking at the Chrome developer pages it sounds like that isn't too far off. Perhaps marketroids pressured the team to get out a Windows version first, so they could make some headlines. Damn marketroids.
And as regular readers of my blog will tell you, I can be a bit salty about young up-and-coming technologies with a chip on their shoulders. Ignore that.
19 comments:
the threads vs. processes topic reminds me a bit of the discussions going on about Rails' multithreading support
On the monetary or otherwise motivations for Chrome: I find it easy to believe that they are both entirely philanthropic and soullessly profit driven at the same time.
I originally read this in conjunction with the Android platform, but basically the claim is: whenever people use the web, Google make money.
It doesn't matter if you use *their* browser, or *their* phone, they still make money as long as you're using the web (via ads and search). But... by pioneering a better (handheld) web experience they can open the platform out wider therefore make more $$$$.
People will position this as a browser war, Chrome vs. Firefox vs. IE but clearly (given the existence of the Gears project) they don't mind you using IE as long as it actually works well and both provides a compelling web experience and doesn't lock you into Microsoft's non-web technologies.
Finally someone who is brave enough to say how things are indeed!
Coming back to using processes is not "One of the most impressive technical innovations that Google has brought to Chrome" - ars, are you listening???
The V8 VM is pretty interesting. The team was lead by Lars Bak (ask your HotSpot colleagues about him). I wonder if any of the technology is shared with Dalvik (it's probably too much to hope they are the same thing!)
As for the motivation that seems quite clear. They want to drive the browser technology forward. One purpose of this project is to get Microsoft to put resources into improving IE. I also wonder if this is going to be the standard browser on Android.
anonymous: I think a lot of people (including me) feel the same way. Google can afford to be grossly philanthropic exactly because they hold all the cards. But I don't think I'm the only one that squints at Google and sees the horrific danger of so much power in the hands of one company. "Do no evil" does not mean "do only good", and we all know what they say about absolute power. Ultimately, though, I think the "browser war" thing will be a non-issue; Firefox has arguably been vastly superior to IE for a long time, and still hasn't unseated it. Chrome's got a major uphill battle, and meanwhile the other browsers can pick and choose bits of it to co-opt. If Chrome ends up being most useful because of what it brings to the broader browser world, I'll happily applaud the effort.
tug: In my brief discussions with Dalvik folks it's painfully obvious there's nothing dynamic about it, so I'm positive V8 is a separate technology.
And as for running Chrome on Android...the process thing seems like it would be a nonstarter there, since even the best Android-enabled devices are going to be a bit resource-limited. Safari on iPhone works so well because it's super-micro (though admittedly almost too micro for some)...meanwhile, the idea of spinning up a process per tab in Chrome on a mobile device is utter nonsense.
I think the motivation with the processes for tabs stuff is not so much memory or multi-threading related. I guess it's rather "security is hard, let's use the OS-built-in mechanisms for it (go shopping)". And security is indeed hard, though not impossible.
What I find disappointing is that they took this path, instead of doing something really interesting, like using object capabilities to create a really secure browser and plugin platform within one runtime. But that's probably too much innovation at once.
"tug: In my brief discussions with Dalvik folks it's painfully obvious there's nothing dynamic about it, so I'm positive V8 is a separate technology."
Interesting...
Google hire a team lead by a man who has done, Self and Smalltalk VMs, headed the initial Hotspot team, did a J2ME VM and then did embedded JVMs for a few years and yet didn't involve him in Dalvik. Well, large companies do some apparently irrational things at times, of course. However I suspect there's at least some shared code technology.
No doubt thinks will become clearer over the coming weeks.
This is the Summer of JS VMs apparently, with SquirrelFish, TraceMonkey and V8 all shipping test versions. It's great to see some experiments being run in that area!
Thanks for the interesting take on Chrome.
"Browsers single-threaded? Maybe 10 years ago. I routinely have a CPU-heavy JS running in Firefox and it doesn't stop me working in other tabs."
I for one routinely have heavy JS apps (I'm looking at you gmail, campfire, and pivotal tracker) contribute to a generally slow browsing experience. Part of the reason I use fluid, in fact.
This feels weird. First of all, the comic wasn't written for someone like Headius who really groks this stuff. There's a vast technical audience which understands threads, processes, garbage collection, fragmentation, etc on the level the comic discusses it, even if it's been dumbed down a little past being 100% accurate.
Threads vs processes is a design strategy; there's not a right answer. Google is clearly looking for a practical solution, not a brilliant new programming paradigm. They aren't wrong when they claim that process-per-tab makes memory leaks drop-dead easy to clean up, even for the user. As mentioned, I'm sure it makes sandboxing a lot easier, too.
They never claim, as Headius implies, that their design is the best possible one. If they don't deeply address all the tradeoffs involved in a comic-book summary of a new product intended for somewhat-technical users, well, what do you really expect? Benchmark results? Statistics on the amount of unused memory and CPU cycles on a typical user's PC?
"Even without GC it's not difficult to use handles ... Perhaps this is the over-optimization of the C/C++ crowd still living large."
If anything is worth optimizing in a VM it's object lookup and access. It represents a huge portion of what OO programs do, and tiny savings here have huge benefits in running programs.
# Threading is hard. Let's go shopping. Or use processes. So now when I have 50 tabs open, it won't just be 50 idle tabs, it will be 50 idle processes all holding on to their resources, not sharing, not pooling. Hmm.
# Not particularly looking forward to seeing 50 Chrome processes in my process lists. The ability to see individual pages as processes and kill them separately does sound intriguing; not sure it's worth every damn tab being a process though.
I disagree with you on these two points. What is shared among tabs? All native code, which is efficiently mapped by operating system. What else would you share? Processes are a security feature, not a bug.
Of course, my argument can be easily disproven, if you show me an equivalent web browser written for jvm using threads and jvm security features for sandboxing. ;)
Charlie,
if you want to use Google Talk on the Mac, consider http://mailplaneapp.com/
It is also a great Gmail client.
Dammit, is this the best Google can do? Oh, right. It is. Never hire a PhD to program a VCR.
Me? I'm waiting for the Erlang web browser. One tab crashes, the rest keep going!
Holy cow, Charlie. Did you get any work done yesterday?
Mario: I've decided to give up sleep in favor of more hacking.
> it will be 50 idle processes all holding on to their resources, not sharing, not pooling. Hmm.
> I do hope there's a way to turn off a tab-per-process, or I can't see myself ever wanting to run Chrome.
I'm sure you know this, but you should mention that because of copy on write, forking off scrillions of child processes isn't as expensive as one might think. Each of those chrome.exe processes you see is not actually gobbling up 22+MB of memory. It does seem a bit anachronistic to go multi-process instead of multi-threaded, but... I guess when we get a Mac version we'll see if it was a good choice or not.
The purpose of Chrome is not to be a "browser", even though Google has to call it a browser. All your points are valid. However, if you start thinking that the real purpose of Chrome is for applications, for front end of "Google OS", for online/offline, for all other stuffs that may not need the traditional browser, then it starts make sense. Google doesn't aim at killing other browsers with a better one. They want to own the whole internet, front to back, apps to pages.
I usually don't buy the processes-beats-threads argument, often made by unix diehards who didn't learn anything better than fork() and sockets for concurrency. And like others mentioned, modern managed (and concurrency-friendly) platforms, like Java or Erlang, can deliver both single-process efficiency and multiprocess-like isolation (at least for security purposes, if not resource mgmt). But in this case, I think google is making a good design choice. Web browsers's memory usage is split in basically four areas:
1) Read-only code;
2) Static, read-only data (metadata for parsing, schemas, UI resources and the like);
3) In-memory cache of web content;
4) The rendered/dynamic content of each page: HTML, images, DOM trees, JS code, socket connections, etc.
For items 1/2, the OS can easily share everything by mmap'ing. For item 3, caching is easy to implement with a centralized controller process (Chrome has it) and simple, safe IPC. (Charles, please don't use Windows' "Mem Usage" counter to check per-process overheads; check "Private Bytes", e.g. with Chrome's about:memory URL.)
For item 4, sharing is typically impossible, because the content is completely different from page to page. The exception is opening several tabs from a single site, then you may benefit from some sharing, e.g. common images or JS files. These are still R/O data, so they're relatively easy to share even in a multi-process architecture. So, the process-specific data goes down to basically the DOM tree and other state, plus read-only content used only by that page... and a single-process architecture would do NOTHING to reduce this footprint. You can easily bring Firefox or MSIE to a half-gigabyte footprint by opening a few dozen heavyweight sites, even within a single process.
And then, the final nail in the coffin is virtual memory management. 500Mb in a single process / single heap sucks if you're tight on physical RAM - if the OS swaps some of it to disk, you may experience very bad performance, because the data of each tab/page is typically scattered all over the heap. On garbage-collected heaps this is even worse, as the GC sometimes needs to visit the whole heap. Virtual memory remais the achilles' heel of the model "single process, loads of threads and huge heap" like we know very well from Java experience.
On the other hand, if these 500Mb are split into 50 heaps of 10Mb each (a typical average size for Chrome's Private working sets), and the OS needs to swap, it can just pick a few processes - those tabs you didn't visit in the last hour - and swap them out, while keeping the private memory of recently-active tabs completely in RAM. This will result in a much better performance in any real-world scenario.
Post a Comment