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."
Re:But... (Score:4, Informative)
Single threaded is the safest way to program. Creating a multithreaded application without a strong multithreaded architecture is asking for trouble.
The only problem with this is the limited performance and the fact that modern computers are packing more and more CPU's whereas individual CPU performance has been stagnating. Sooner or later people will have to work out the tools to create safe multithreaded applications without requiring a special degree in parallellization.
Re:SetTimeout (Score:5, Informative)
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 [whatwg.org].
Re:SetTimeout (Score:5, Informative)
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:But... (Score:5, Informative)
What the article is saying is that each instance of the JavaScript runtime runs in one thread. If you want multi-threaded JavaScript, you need multiple runtime instances (one per thread). This is how WebWorkers work.
Re:But... (Score:5, Informative)
Basically in a dynamically typed language like JavaScript every property access, function call, or any other thing that can be changed dynamically could be changed at runtime by another thread. So you need locking for every method call, property access, etc to make sure it isn't changed by another thread while it's accessed in another.
There are some generally fast locking algorithms for when locks are used mostly by the same thread... for instance in Java locks can be owned by a thread and that thread never has to lock or unlock at all, but instead it periodically checks if another thread has written a flag saying it wants to become the owner, then there is synchronization to pass off ownership. This works ok for Java, where there are fewer things that can change at runtime and they are explicitly listed out (using 'synchronized'), but in a dynamic language it's usually just too much overhead.
Just for comparison V8 is even more extremely single-threaded, with execution that can only be interrupted at some certain points in the JS code.
Re:You had me at.. (Score:5, Informative)
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:But... (Score:4, Informative)
http://www.gotw.ca/publications/concurrency-ddj.htm [www.gotw.ca]
Re:You had me at.. (Score:5, Informative)
Often (Not all the time) you come to a trade off of performance vs memory usage.
Sometimes it is better to store a bunch of data in memory just for quick reference then having to calculate it over and over again or worse need to get it from slower storage such as a disk.
Now there are things you can do to optimize the memory usage so it isn't as wasteful. However if you goal on low memory foot print chances are you are going to be sacrificing performance to use less memory.
A mistake (Score:4, Informative)
My initial sense of this, is that they are making a huge mistake here. I'll have to do more research, but my feeling is that they are moving in the wrong direction with this decision.
One of the really cool "baked in" things with functional style language is their fundamental support for horizontal scaling across CPUs. My hope has been that javascript evolves towards this, so that the generic suite of functional methods become massively performant on a larger scale with map/reduce/fold/each calls.
Closures present a bottleneck here, but it seems like a reasonable runtime could make some intelligent prediction about whether the isolated function is a closure or not, and ship it off to a different CPU/thread depending on optimization strategies, or even estimated closure size. Even better, this could be done at runtime with some runtime optimization based on execution metrics of an anonymous/declared function in-context.
At the point of calling the map/reduce/fold/each function, the runtime should be able to decide whether to parallelize out the call, or even use some language extensions to let the developer specify the threading.
The point is, now that they're making this decision, all of those options are gone from FF. And at a terrible time too. As we move toward CPU architectures that encourage parallelism, Mozilla is taking js off the table as a first-class language able to easily exploit those new architectures. That strikes me as a huge mistake, and I'm struggling to understand the rationale.
Re:You had me at.. (Score:5, Informative)
Have you told firefox not to remember all your downloads indefinately? It gets a little slow when it's remembered a couple of hundred downloads, and that was the default setting a long time ago, if you've been upgrading and never reinstalled your OS you've probably still got that default setting.
In saying that, I use chrome now, once they decided to start bumping major versions every month or so, and upgrading broke at least one extension for a week, it was time to move to chrome. Oddly when I did I still preferred the FF UI, course now they have changed that to be more like chrome anyway.
Re:You had me at.. (Score:3, Informative)
Please cite a documented case that isn't caused by an extension.
Firefox hasn't had any major memory leak problems since Firefox 2.
Re:You had me at.. (Score:5, Informative)
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.. (Score:3, Informative)
https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Firefox&content=leak&comments=0 [mozilla.org]
Re:You had me at.. (Score:2, Informative)
I'm a Firefox fan, but even they've stated they had very bad memory problems.
See this link: https://wiki.mozilla.org/images/9/93/LCA2012.pdf
Re:You had me at.. (Score:5, Informative)
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 [slashdot.org]
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.
Comment removed (Score:5, Informative)
Re:You had me at.. (Score:5, Informative)
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.. (Score:5, Informative)
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 [jlebar.com]
Re:You had me at.. (Score:3, Informative)
If you want to do something constructive about it rather than just ranting, file a bug (preferably with a self-contained testcase attached) and CC :njn and :jlebar to help triage.
Re:A mistake (Score:4, Informative)
The old JavaScript runtime supported multi-threading in the runtime itself. This resulted in the need for complex threading/locking code to make sure that data was being accessed correctly. This is hard to maintain, easy to get wrong, consumes more memory and slows down things like garbage collection.
The new JavaScript runtime is single-threaded. WebWorkers each have their own instance of a (single-threaded) JavaScript runtime that may be running on different threads.
You can still have your map/reduce/fold/... functions running in parallel; they will be implemented on top of WebWorkers. As the representation of each runtime is simpler, the engine as a whole can optimise the work between threads better and perform better code generation.
It also means that garbage collection is faster as it (a) does not navigate all memory allocated across all threads and (b) only blocks the thread the garbage collector is currently running on.
Re:OM NOM NOM! (Score:4, Informative)
A dozen tabs huh? Okay, I get a dozen tabs open, including Facebook, G+, a few Amazon pages and Slashdot. I've got NoScript and Firebug installed.
My Firefox 9.0.1 is using 1.3 GB of virtual, but only 514 MB of real, actual memory.
Double check what the title of the column is where you're reading the memory usage from. Or try looking at about:memory in Firefox.
Re:Caring (Score:2, Informative)
If you have an SSD, disable swap. There's no reason to be continually writing to one section of the disk. If you must have swap, use a spinning disk. Also, assuming you're running linux, you should set swappiness=0. Depending on your SSD repeated writes *may* not be an issue, but pretty much all of them fail catastrophically and without warning when they do fail.
There's a bit more optimization you can do with SSDs but I'll leave that as an exercise to the reader.
Re:The boy who cried "Leak!" (Score:5, Informative)
Firefox has 400 million users. (That's 1/20th the world's population, for those following along at home.) Any time we make a UI change, some of these 400 million people will love it, and some of those 400 million people won't. I'm sorry you didn't like this change.
There's an add-on to get the status bar back. Can we move on, please?
https://addons.mozilla.org/en-US/firefox/addon/status-4-evar/ [mozilla.org]
Firefox 9 unusably slow on system with 128M of RAM (Score:5, Informative)
As an exercise in insanity, I tried to install a modern Linux distro on an old Pentium II system with only 128M of RAM. Used btrfs for the heck of it. It was all going well until I tried to run Firefox 9.0.1. Thrashed that system mercilessly. Never mind actually showing a web page, just starting up blank was extremely slow. Sometimes I saw the "unresponsive script" popups on Firefox's own Javascript. I hacked out everything that used memory, dumping the LXDE desktop environment for a plain old window manager (jwm), and this helped, but it's not enough. Turned off images and disabled Javascript. It still thrashes swap.
Chrome didn't do any better. Firefox 3.5 worked okay on an even smaller system (96M of RAM). Version 3.6.8 + LXDE works fine on a system with 192M of RAM. Here's hoping their MemShrink effort scores more big wins.