Firefox Javascript Engine Becomes Single Threaded

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

Comments

You had me at..

[Sez Zero]

"memory savings".

Re:You had me at..

[Anonymous Coward]

There's a reason they're the most efficient browser when it comes down to memory usage. They actively work at it.

Re:You had me at..

[hedwards]

Which is why they always cream the competition in the benchmarks? Seriously, the only time I've ever seen it waste memory was during a session where Silverlight crashed. In general it tends to use very little in the way of memory.

OTOH, given your post, I can only assume that you're using lynx, tons of extensions or are some sort of troll.

Re:You had me at..

[Anonymous Coward]

Sorry, "leaks memory like a BP pipeline" sounds like the best description for a browser which seems to absolutely refuse to free up RAM used by old images loaded by Javascript that have since been kicked off the page. I can set up a timer to reload an image every, say, half hour* (think "weather report precipitation map" or "webcam image") on a machine that should be up 24/7, come in the next day, and have Firefox's "This page has a script that is not responding" popup because the OS was too busy thrashing swap after physical RAM filled up and Firefox thought it was the script's fault. It's not often I see the Mem and Swap meters in GKrellm2 solidly maxed out. For debug purposes, I can have it reload that image every five seconds and watch the memory steadily creep up every five seconds without ever doing anything resembling GC. Of course, if I close that tab, the memory returns instantly.

Now, you might say that for a kiosk that should remain up 24/7 like that, I should consider a different means of presenting the data. And ultimately, I did consider a different means. Because neither Chrome/Chromium nor Opera have this problem. Using the exact same script on both browsers, once it reloaded the image, the old one was booted out of memory immediately, or at least quickly enough that any extra memory use was marginal and incidental, and certainly not to the point where it would suck down all of swap like Firefox did. In fact, this script is still running on a kiosk here, it has been for a couple weeks straight now, and there's no memory wasting in sight. Firefox wouldn't have lasted the first night without manually reloading the entire page.

So yes. It's Firefox. Firefox leaks memory. A lot. It does this due to very poor cache decisions and inferior GC techniques. Period. This has been a known problem for some time; a cursory glance through Stack Overflow will find numerous questions regarding this exact situation and Firefox, none of which have conclusive answers besides "stop using Firefox". And the only common thread in all of them is Firefox. The problem is Firefox. Firefox is the problem. It leaks memory.

*: Note that this is using the trick of appending the image's URL with a dummy timestamp variable to trick Firefox into not just loading the old image from cache despite pragmas and meta tags telling it not to. Point still stands, though: Chrome/Chromium and Opera understand enough to unload the previous image from RAM with the exact same script and usage.

Re:You had me at..

[kbg]

What, the hell are you talking about?

Didn't you read this slashdot article: http://developers.slashdot.org/story/12/01/17/1338225/notes-on-reducing-firefoxs-memory-consumption

Here is one of the relevant parts from the Firefox developer:

"Finally, Firefox 4 had a new HTML5 parser. It had a bug which meant that every time you set an innerHTML property on an element, some memory would leak. And that’s a pretty common operation on many websites. "

Please think before you post again.

Re:You had me at..

[MightyYar]

Me to friend: Use Firefox! It has these awesome extensions! Definitely install AdBlock Plus, NoScript, Tree-Style Tabs, Auto Pager, IE Tab2, GreaseMonkey, Firebug, and the Developer Toolbar!

Friend: Does your Firefox use every bit of your system's memory?

Me: Pffft, well, only if I use the extensions!

In all seriousness, they need to do something about the extensions. Refuse to host leaky ones or something. Extensions can't be Firefox's killer feature if they make it eat all of your RAM.

Re:You had me at..

[KiloByte]

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:/// 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..

[Anonymous Coward]

Of the 38 bugs listed there, about 5 were not memory leaks according to the subject. How many of those were because of addons?

Then clicking on the first few bugs:
- ONE GUY had addons and the dev requested a no-addon test. No reply.
- This one look more promising but when the dev said "To find out it's a real memory leak or not, run 'prstat' command in a terminal.
If the vaule of 'RSS' field of firefox row keeps increasing, it's a memory leak."... No reply.
- ONE GUY had problem spamming the same URL into the URL bar. "Maybe have to close it" sounds like he wasn't even sure. Not a typical use case. (don't spam the URL bar with the same URL.
- Agan one guy.
- "The numbers you quote are not exceptional at all. They're probably caused by the malware-database that is updated in the background"
- "The fix in bug 426236 fixes all the leaks, but it doesn't touch controllers..." fixed in 2008, but left open "just-in-case"

Maybe you should actually look at the things before linking them?

Re:You had me at..

[jlebar]

In all seriousness, they need to do something about the extensions. Refuse to host leaky ones or something. Extensions can't be Firefox's killer feature if they make it eat all of your RAM.

We are so on this. In fact, add-ons are the majority of what we talk about at MemShrink these days.

In theory, leak checking is now part of the addons.mozilla.org review process, so new add-ons will all undergo a (very basic) leak check before they're approved. I'm sure we'll have to tweak as time goes on, but it's a start.

http://jlebar.com/2011/11/13/The_carrot%2C_the_stick%2C_and_the_wrench%3A_Add-on_leaks_are_everyone's_problem..html

Re:You had me at..

[bursch-X]

You've got an 8GB system and complaining about FF 3.6 memory leakage?

I'm not sure whether you are aware of it, but there's this cool way of replacing your application with a newer version (new: less than two years old). For free! It's called updating. I'm aware it's a radical concept, but try it out, it's pretty cool.

SetTimeout

[Anonymous Coward]

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

[The MAZZTer]

I am going to assume you are aware of how those functions work (specifically that they cannot interrupt the current thread if it is busy; they are only handled if the thread is idle) and that they themselves are not multi-threaded or have anything to do with multi-threading. It's not 100% clear from your post, though.

Multi-threading in JS is handled by web workers.

Re:SetTimeout

[Anonymous Coward]

The same way it's always been implemented. setTimeout is event driven; it adds an event to the event queue to be executed at a later time. Once your code returns, the browser can spin the event loop again. The timer event will come up in due course and the browser will reenter the js engine to call your function.

Re:SetTimeout

[The MAZZTer]

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);
for (var i = 0; i < 10000000; i++) { // Maybe do something in here that takes awhile. }
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.