Firefox Javascript Engine Becomes Single Threaded 346
An anonymous reader writes with news about work on Mozilla's Javascript engine. Quoting Mozilla engineer Luke Wagner's blog: "With web workers in separate runtimes, there were no significant multi-threaded runtime uses remaining. Furthermore, to achieve single-threaded compartments, the platform features that allowed JS to easily ship a closure off to another thread had been removed since closures fundamentally carry with them a reference to their original enclosing scope. Even non-Mozilla SpiderMonkey embeddings had reportedly experienced problems that pushed them toward a similar shared-nothing design. Thus, there was little reason to maintain the non-trivial complexity caused by multi-threading support. There are a lot of things that 'would be nice' but what pushed us over the edge is that a single-threaded runtime allows us to hoist a lot data currently stored per-compartment into the runtime. This provides immediate memory savings."
SetTimeout (Score:5, Interesting)
Maybe I'm missing something, but then how will "threading" (i use that term extremely loosely) methods like SetInterval and SetTimeout be implemented?
Re:SetTimeout (Score:5, Interesting)
Oh I read your post wrong; anyways I did answer your question in the first bit.
Code sample:
setTimeout("alert('This alert fires second.');", 0); // Maybe do something in here that takes awhile. }
for (var i = 0; i < 10000000; i++) {
alert("This alert fires before the other one.");
Either your browser will display the alerts in the proper order despite the 0ms timeout (because timers are only handled when idle because they are NOT threaded) or your browser will get angry at the 10,000,000 iteration-long loop.
Re:us to hoist a lot data currently (Score:4, Interesting)
They mean to replace multiple per-thread copies of data with one single copy of it, accessible by all threads. No doubt part of Mozilla's latest push to reduce memory consumption.
One feature of x86 is that, save for a specialized SSE streaming store instruction, any store made by one core is immediately visible to all the other cores—even when the old value was already in a core's cache.
Maintaining such cache coherency involves a lot of overhead, so to get better scalability multi-threaded apps will sometimes adopt a "share-nothing" model: all threads get their own copy of the data, and no other threads will ever get to touch it. You trade memory and complexity for speed.
It sounds like Mozilla has decided this trade off is no longer worth it, and so has done away with multi-threading all together. Perhaps they will use green threads [wikipedia.org] instead of native threads, though that brings along its own bag of complexities.
Re:You had me at.. (Score:3, Interesting)
So...can we put this cliche to bed now?
Considering how appalling the memory leaks were for YEARS while the moz folks insisted there weren't any problems, it will probably take at least as many years before any of us believe anything they say about memory usage.
I for one, won't believe they have any competence in memory management until I have spent 5 years without having to restart Firefox every other day.
Re:You had me at.. (Score:5, Interesting)
Where do you pull that "3X faster" from? Without proper AdBlock, Chrome seems to be only about as fast as Firefox. With AdBlock installed and properly configured (ie, not just the defaults, including "non" (hah) intrusive ads), Firefox runs circles around Chrome. If you can't bother setting it up, try NoScript.
That's just speed. Now try to factor in privacy, features or configurability. For example, in their default setting, Chrome crashes to desktop if you close the only tab. Someone on the Firefox team had the "brilliant" idea to ape that, and sadly, Firefox does that by default as well now. But fear not: "Close Last Tab" restores sanity. Also, tabs on top: I find myself using keyboard to access tabs only ~50% of the time -- the tab bar is accessed at least an order of magnitude more often than the URL bar, thus it should be more accessible. Again, the Firefox team aped Chrome's misfeature, but you can restore sanity easily. Get rid of the useless search bar? Here you go. Get rid of Google's typo-jacking? browser.fixup.alternate.enabled=false and keyword.enabled=false (you can type "google goat porn" if you want to search; rename the default keyword to "g" for convenience). Fix the http:/// [http] being hidden for 1/3 sites that still didn't go SSL? browser.urlbar.trimURLs=false. And so on, so on.
Re:You had me at.. (Score:5, Interesting)
When my FF 3.6.3 gets above 1GB of virtual memory, it becomes a sluggish pig on my 8GB system. Frequent half second pauses. Characters blurt out ten at a time when I'm typing into a simple web form. I've always assumed this was a GC gag of some kind with worse than linear scaling as memory fragments.
If it was using 2GB and never slowing down, I'd write it off as the cost of having a plug-in architecture. I have a lot of plug-ins. That's the whole point.
Re:OM NOM NOM! (Score:2, Interesting)
And my Opera 11.60 with 23 tabs running for two weeks uses 919M virtual, 630M private and 527M physical.
Looks like FF is as memory hoggish as ever.