Tuesday, September 2, 2008

A Few Thoughts on Chrome

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.
  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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!"
  6. 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.
  7. 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.
  8. 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).
  9. 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.
  10. 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?
  11. 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?
  12. 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.
  13. I'm glad browser address completion has been made "really compelling" finally.
  14. 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!
  15. 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.
  16. 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.
  17. Ahh, there we go, an "incognito tab" for private browsing. Seems like a good way to go.
  18. 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.
  19. 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.
  20. 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?
  21. 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.
  22. 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."
Overall I'm sure it will be a really excellent browser that I may or may not use. Partially because Google's client app support is basically nonexistent for OS X (how long has Google Talk been promised for OS X?), and partially because...I dunno...I feel better using a browser not designed and controlled by an ad-funded megapower. I'd rather not allow Google to control the vertical AND the horizontal. Not that I have anything against Google in general. This blog is hosted on Google-powered Blogger, I use Google for search pretty much exclusively, and I host services for my personal domain headius.com on Google as well. But it seems disingenuous to say Chrome is supposed to "help everyone" and yet nobody gets to see any of it until they're in beta. I guarantee Firefox folks would have started integrating portions as soon as the code were opened up, which of course would have taken some steam out of the eventual announcement. Try to look past the fireworks and bluster, folks.

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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. I picked a tab at random to forcibly kill and the entire browser disappeared. I guess I picked the right one.
  7. 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.

13 comments:

  1. the threads vs. processes topic reminds me a bit of the discussions going on about Rails' multithreading support

    ReplyDelete
  2. 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???

    ReplyDelete
  3. 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.

    ReplyDelete
  4. 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.

    ReplyDelete
  5. "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.

    ReplyDelete
  6. 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.

    ReplyDelete
  7. "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.

    ReplyDelete
  8. "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.

    ReplyDelete
  9. # 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. ;)

    ReplyDelete
  10. 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!

    ReplyDelete
  11. Holy cow, Charlie. Did you get any work done yesterday?

    ReplyDelete
  12. Mario: I've decided to give up sleep in favor of more hacking.

    ReplyDelete
  13. > 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.

    ReplyDelete