Slashdot Mirror
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."
"memory savings".
Maybe I'm missing something, but then how will "threading" (i use that term extremely loosely) methods like SetInterval and SetTimeout be implemented?
"us to hoist a lot data currently stored"
I really wish I knew what this phrase meant. It sounds fascinating.
But seriously, if there's no performance gain from multithreading, it can be a really good idea to move away from the complexity of it. There's a lot of traps people can fall into with concurrent code if they don't know what they're doing.
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.
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.
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.
http://www.gotw.ca/publications/concurrency-ddj.htm
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.
Drinking habits can be dangerous. You can choke on the cloth and the nuns will wonder where their clothes are.
Multi-threading in JS is handled by web workers.
Oh, great! So now we're outsourcing even more textile jobs to anyone willing to work online, is that it? Sheesh!
(On a more serious note, thank you for that informative link.)
"What in the name of Fats Waller is that?"
"A four-foot prune."
So while they may have fixed most of the memory leaks (it still runs like shit on a Mac), let us not allow them to get complacent again. [snip] By not frequently reminding them about memory leaks, you are opening the door to yet more bloat going forward.
I believe there's a parallel with a common fable:
You saw a wolf. I said I shot many, that the wolf situation should be improved, but you kept seeing wolves. This repeated many times and made you angry.
Now lots of others are saying that there really are fewer wolves these days. Indeed, you have no reason to believe that they're wrong.
But because of the offense done to you some time ago, you're going to continue crying wolf, even given no evidence at all?
I don't understand. I guess this is an attempt to punish us? Is it that you feel like we harmed you with our lies, so you should try to harm us with yours? I'm afraid that by crying wolf, and encouraging others to do the same, may just cause us to ignore you all, which is exactly the outcome you don't want.
I'm very sorry you feel like Mozilla deceived and harmed you. But the malicious attitude here and elsewhere in this thread is getting old. Use Chrome, if you like! But don't encourage people to waste developers' time with false claims.
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.
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.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"