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."
You had me at.. (Score:5, Funny)
Re:You had me at.. (Score:5, Funny)
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.. (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.
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: (Score:2)
No trolling at all. Latest versions of Firefox are better behaved regarding memory usage than former ones, specially with only a few tabs open, but will still leak memory steadly over time.
Oh, and i like Opera, thank you very much.
Re: (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: (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: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: (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.
Re: (Score:2, Funny)
And we're on what now, Firefox 82?
Re: (Score:3)
Out of curiosity, is that actually a significant memory leak? Yes, it's extremely bad form and the kind of thing that should be fixed ASAP. But did it result in a typical leak rate of a few KB per day, or would it lose 100MB an hour? Without that kind of information there's no way to tell if that's a real problem that affects people, or something more theoretical that should be fixed because it's the right thing to do.
Re: (Score:3)
Yes I would say so, innerHTML is used very much on many websites, it is especially bad when you have a site with dynamic content being refresh on an interval. But that is besides the point, all memory leaks are bad, when you have your browser running constantly for many months, any memory leaks wreak havoc. In this day and age having memory leaks in your application are a sign of bad developing practices and not enough testing for releases. The Mozilla team has a habit of focusing on useless stuff like tab
Re:You had me at.. (Score:5, Insightful)
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.
OM NOM NOM! (Score:2)
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.
I can't agree more. Things are much better than they used to be, but oofda. So much for 640K -- FF is currently using up almost 1GB with about a dozen tabs open, and with AdBlock Plus, NoScript, IE Tab2, Firebug, User Agent Switcher.
Cheers,
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: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:4, Insightful)
That is awesome - thanks. And I just read your team's memory presentation by Nicholas Nethercote [mozilla.org] :)
Re: (Score:2)
Refusing to host obvious leaky ones will help, but I'd like to see some sort of memory/performance meter done well. Make it dead simple to see which extension/plugin is leaking. If one is behaving worse than some threshold value, encourage the user to look at the bad boy. Preferably with a solution available (reload or delete plugin/extension).
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:You had me at.. (Score:5, Funny)
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.
Re: (Score:3)
I've finally figured out the cause of [most of] the pauses. It's the session restore feature that saves the browser state, cookies, and session data every 10 seconds (in JSON format, no less). I've turned it off and the pauses are now almost entirely gone.
Naturally, this will remove the feature that restores your tabs in the event of a crash, but seeing how little Firefox blows up on
Caring (Score:3)
We live in a world where 8GB of RAM costs $50. I'm not sure how much I actually care whether Firefox uses 500MB vs. 2GB anymore.
If only four applications you keep open all the time feel the same way you start caring quickly.
Swap is still annoying. Even when you have an SSD and cannot hear it...
Re:You had me at.. (Score:4, Insightful)
> We live in a world where 8GB of RAM costs $50.
Ah sweet, so you're offering to pay for upgrading/replacing netbooks and embedded devices with more RAM !
Stop being a myopic PC developer with RAM means nothing -- there are other platforms where we actually care about RAM usage.
Re: (Score:2)
We live in a world where 8GB of RAM costs $50.
The problem is that two of my otherwise favorite applications, Firefox and Crashplan, each gobble up memory until my system shows a spinny beachball of death every time I try to do the simplest thing. Even when your system has plenty of memory, performance suffers when applications start hoarding gigabytes of it.
Re: (Score: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: (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: (Score:3)
Technically speaking, I don't think that fits the criteria of a memory leak. As I have always understood it, a memory leak is when a piece of memory has been allocated by the program, and then the program drops the reference to it without releasing it. This memory is then 'orphaned' and can't be found or used by any program.
In any case, I think you have accurately connected it to garbage collection and cache management, and it should be fixed if so. So your point still indeed stands. :)
Re: (Score:3)
It's only a GC and cache problem IFF the GC actually knows the memory needs to be freed. If the GC doesn't realize that the memory needs to be freed (even though it's not being used), it's a memory leak.
The garbage collector isn't some magical plastic memory cover that makes memory leaks bullet proof. Just because you don't have to manage your memory in Java doesn't mean a shoddy programmer can't write something that'll take up more and more memory, if only because he neglected to design the program in such
Re: (Score:2)
Comment removed (Score:5, Informative)
Never need to restart firefox (Score:3)
As a separate data point, I've never had to restart firefox either on my 8GB work laptop running linux or on my 3GB home laptop running Win7.
Re: (Score:3)
I'm giving up. I downloaded Firefox 3.6 from Mozilla's website last night. I'm going to make it my default browser.
You know they're forcibly upgrading FF3.6.x to FF12 in April, right?
And that's when I bother to switch to another browser. I consider FF8 to be different enough (in ways I don't particularly like) to essentially be a different browser. If I'm going to go through all that trouble, I may as well switch completely. Chrome seems to be out, as (1) I don't particularly trust Google any longer, and (2) it seems to take a lot of RAM on my system (no I haven't investigated why, and I don't care to). Safari, on Windows? HAHAHA. IE8? Double fucking HAHAHA. So no, I haven't decided wha
Re: (Score:2)
Which is why they always cream the competition in the benchmarks?
BWAHAHAHAHAHAHAHAHA
Re:You had me at.. (Score:4, Funny)
Re: (Score:2)
Yeah, it's not like it leaks memory like a BP pipeline.
Used to. [mozilla.org]
So...can we put this cliche to bed now?
Re: (Score:2)
You want it to leak all over your bed??
Ewwww.
Re: (Score:2)
Yeah, it's not like it leaks memory like a BP pipeline.
Used to. [mozilla.org]
So...can we put this cliche to bed now?
Not until they clean up all the residual memory!
Re: (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: (Score:2)
You do largely have a point, but during that time there was a workaround. If you for whatever reason didn't want to close the browser regularly there was a memory trim on minimize fix that would force it to trim memory. I found that to work effectively.
But, yes you are correct between the 2.0 release and the 3.5 release where it was fixed that was about 3 years. Although, I probably should give them some credit for the time during which they were fixing it.
Re: (Score:2, Insightful)
No. Let's not.
Simply because Firefox devs are some of the most complacent, or downright willfully arrogant folks out there. It took years, literally years, for them to even admit there were massive memory leaks in Firefox. Anyone who suggested it here was branded a troll by them -- but that was back in the day when people liked, believed, and trusted in Firefox, back in the days when it was on its ascendancy. Those days are well and truly over.
So while they ma
The boy who cried "Leak!" (Score:5, Insightful)
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.
Re: (Score:3)
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.
I feel the need to chime in here, because my original (humorous) post started this flood of responses. I like Firefox a lot, but still, I experience memory leaks all the time, even with latest versions. And from what i hear, i'm not alone either. It is not mass delusion.
Now, some people to this subject respond passionately, like if their favorite team were involved, which just boggles my mind.
I really appreciated when the FF team started addressing memory usage not too long ago (it really has improved thing
Re: (Score:3)
My experience: I can't load Yahoo Mail for any length of time in Firefox without it turning to mush. If I leave Firefox open for a couple of days with mostly static tabs, twitter excepting, and make the mistake of using other applications, it'll turn to mush. And by mush I mean swap hell when you try to scroll a web page, that kind of thing.
[snip]
So... look, if we didn't love Firefox, we wouldn't be upset.
If you love Firefox, please file a bug (bugzilla.mozilla.org) and cc me [:jlebar]. Bugs from the community are how most of these problems get identified and fixed -- we simply don't have the testing resources that Google, Apple, or Microsoft has. We rely on you guys as much as you rely on us.
If you file a bug (or if anyone else reading this thread files a bug), I promise I'll take a serious look and try to understand your problem.
Re: (Score:3)
"My experience: I can't load Yahoo Mail for any length of time in Firefox without it turning to mush. If I leave Firefox open for a couple of days with mostly static tabs, twitter excepting, and make the mistake of using other applications, it'll turn to mush.
And by mush I mean swap hell when you try to scroll a web page, that kind of thing.
This isn't just happening on my 1.5Gb VM at work or 1Gb Netbook, it's happening on my 8Gb freshly installed no-profile-other-than-that-produced-by-Firefox-sync no-extensions-even-AdBlock Ubuntu machine."
Sweet jesus, man, he just gave you a description right there. Although I'm not on the FF dev team, that sounds like a damn memory leak to me.
This is a common /. misconception, that "bug reports" like this are actionable.
There are so many things missing from this: The reporter's operating system, which version of Firefox is affected, whether Firefox is actually swapping or the disk is spinning doing something else... We'd want to see if the garbage collector is making Firefox slow. We'd want to see if a newer version of Firefox doesn't have this problem. Like another poster said, we'd want to have a look at about:memory before and after the p
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]
leak semantics (Score:2)
For me it only counts to blame the leak on a plug-in if they tell me which plug-in to nuke. If I disable 15 plug-ins, it's not even the same browser by the time I'm done. Why do all these extension leaks persist? Because there's no feasible way to push a complaint into the right bug queue. Who is responsible for this sorry state of affairs? FF-core.
In my opinion, any lost memory not attributed to a specific culprit is a leak in Firefox, the product.
I'm thrilled with the progress they've made with FF-co
Re: (Score:2)
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: (Score:2)
Chrome always chrases me on this site: index.hu
It says the flash plugin froze, but it works flawlessly with Firefox.
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: (Score:2)
If I wanted to close the program, there's that button in the corner of the window, or Alt-F4, or Ctrl-Q. That's different from a request to close the tab (ie, the tab close button, or Ctrl-W). No other MDI program does that. It's a failure to conform to commonly agreed upon standards, for no reason whatsoever. Be that a bug or a misfeature, the end result is the same: the program suddenly quit when it shouldn't have.
Re:You had me at.. (Score:4, Insightful)
"Chrome is 3X faster"
Dear sir, how did you obtain such an accurate measurement?
Re: (Score:2)
Honestly, Chrome is 3X faster than Firefox.
If we're talking about JavaScript execution, then yeah, the difference is at least that much. Last year, I tried writing a game in JavaScript, since all the cool kids are dropping Flash nowadays. It worked fine on Chrome, but was completely unusable on FF. Running it in WebKit on Android, on hardware that's puny compared to my desktop, it still ran better than in FF.
Which is a real shame, because overall, FF is my favorite browser. I like the configurability, I like the wide selection of plugins, I like the
Re: (Score:2)
Well, Chrome is made with C/C++, while Firefox is almost done entirely in JavaScript. Chrome is a real native application, while the Firefox native bit only have the minimum required to run a JavaScript interpreter
Troll Harder!
Re: (Score:2)
Me too. At first I was like "Yay!", then I said to myself: "let's wait and see".
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: (Score:3)
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, 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:angry (Score:2)
So wait, if you run that in Songbird Browser does it become an Angry Bird? : )
*More* outsourcing?! Bloody "globalization"! (Score:4, Funny)
Multi-threading in JS is handled by web workers [whatwg.org].
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.)
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.
Can't tell if trolling or serious (Score:2)
Re: (Score:2)
Proactor pattern? Is that really a thing?
No. It's a stupid name for long-running tasks running in a separate context and calling a handler on completion (in unspecified context because people who define this stuff are stupid).
It also has nothing to do with anything being discussed.
Re: (Score:2)
Yeah ... http://en.wikipedia.org/wiki/Proactor_pattern [wikipedia.org]
us to hoist a lot data currently (Score:5, Insightful)
"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.
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: (Score:2)
Sounds like a cop out due to poor implementations to me.
It's not a cop out. You don't gain an advantage from multi-threading if your threads run on different cores. The main advantage of threads was avoiding a context switch during a blocking call. This way switching to another thread was cheaper. And since they ran on the same processor, it meant that you HAD TO switch to another thread. But on multiple cores they often run simultaneously. So if you have (for example) 2 threads running and one blocks, you won't get the advantage of avoiding a context swit
Re: (Score:2)
main advantage of threads was avoiding a context switch during a blocking call. This way switching to another thread was cheaper.
But that advantage mostly went away before the core count started climbing. There's still a bunch of context to swap on a thread switch - the main difference on a process switch is swapping the memory mapping context, and processors have been optimizing for that specific action for quite some time, and it's no longer particularly expensive in the scheme of things.
I don't see the need for threads in a broswer plug-in. I can't imagine living wothout them in back-end infrastructure code: no one gets taught a
Re: (Score:2)
LoB
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: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.
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.
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: (Score:2)
whereas individual CPU performance has been stagnating
Except not. The cores themselves are also more efficient and performant as well. Performance != gigahertz rating.
Re:But... (Score:4, Informative)
http://www.gotw.ca/publications/concurrency-ddj.htm [www.gotw.ca]
Re: (Score:2)
Relatively speaking, core performance growth has slowed down drastically. Most of your integer based logic and math have a throughput and latency of 1 cycle. Hard to get much lower than 1 cycle. The only real advancements in speeds are multi-cycle instructions, and most of those are SIMD now.
Lets go Irrational then!
Re: (Score:2)
That's too complex for me!
Re: (Score:2)
Oh, get real.
Re: (Score:2)
I was curious about that myself. Multithreaded should better for performance when one has multiple scripts and multiple tabs.
But, I do see your point, if the tools aren't there to make things work together, I kind of wonder if that isn't part of the problem I've been having lately with scripts not responding and the interface freezing randomly.
Re: (Score:2)
Sooner or later people will have to work out the tools to create safe multithreaded applications without requiring a special degree in parallellization.
Maybe as soon as they figure out IPCs. Before answering the question "aren't single-thread programs bad", you have to mention the difference between a thread and a process. Once one realizes that the main advantages of a multi-threaded paradigm were in single-processor space (because it allowed to avoid a context switch necessary for changing memory space to that of a different process), you won't even have to explain the rest. Most people have already come to expect that multi-core is a Good Thing(TM).
Re: (Score:2)
That's training.
As the internet continues to develop and fewer people started out with dial up, I'm not sure how long that's going to remain the case. I remember having to use a crappy web app at a previous job logging things and it would freeze or crash so frequently that standard practice was to log everything on paper first and then copy that into the application.
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: (Score:2)
That makes a lot more sense than the title suggested. The Firefox devs have been working for quite a while to split the browser up to better make use of multicore processors and it seemed a bit odd that they would be going backwards and cramming all javascript into one process.
Of course the article said as much that these containers are on a per tab basis and hopefully that will help people who have tons of tabs open at once still be able to browse when one unrelated script freezes on a different tab.
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: (Score:2)
This has little to do with dynamic typing; anytime you share mutable state between threads, anything mutable in the shared state could be changed at any time by any thread (in particular, statically typed languages which allow arbitrary pointer manipulation -- like C/C++ -- have this problem just as much as dynamicall
Re: (Score:2)
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.
So, I write Java a lot (java/jogl actually) and we do quite a bit with multi-threading. usually we use reentrant locks where anyone that wants to read/modify needs to lock/unlock, even the lock owner. you can't just assume the owner can check if nobody is owning it because, if it is currently changing something and then another object in another thread requests the lock, the owner won't know; it needs to lock the lock as well so other threads know to wait.
Also, synchronized is not a way to denote what c
Re: (Score:3, Funny)
It's an evil sentence for saving the tiranny originated by the supposed saved Queen
I'm puzzled. Since when does the UK have such a strong pro-Albanian foreign policy?
Re: (Score:2)
class-based, typed and multi-threaded
You mean... Java?
Re: (Score:2)
Just because you have 64-bits doesn't mean you have to use them for everything. I suppose you insist upon using a 64-bit text editor as well. Considering how much time and energy the developers spend trying to minimize memory use, I'm not really sure why they would go and undo all that just to use 64bits.
Re: (Score:2)
The AMD64 instruction set and the ABI are so much better than on i386/i686 that you definitely should.
Re: (Score:3)
You have twice as many registers, which are each twice as big.
Spilling to memory is much more costly than a cache miss.
Plugins/Extensions (Score:2)
Web Browsers are much more sophisticated than a text editor. If all you used them for was rendering html, then 32-bits would probably be fine. But, 64-bit could potentially be nice for things like 64-bit plugins and extensions - true, most plugins/extensions are just fine as 32-bit apps, but there could be some specialized plugins which might benefit from access to full memory.
Re: (Score:2)
Unless 32-bit support is being dropped from operating systems can you explain why it is bad that there is not a 64-Bit version?
Re: (Score:2)
32-bit Inel assembly is crap - extremely limited registers, and an instruction set full of legacy baggage form the 8-bit days. AMDs add-ons for 64-bit are modern, lots of registers and a set of sensible instructions to use them.
So it's a trade-off: 32-bit uses less memory (including for the instructions), and is therefor morelikey to get processor cache hits , while 64-bit gives you more registers, which allow signficantly faster code when (as is normal in non-scientific programinng) everything you care abo
Re: (Score:2)
Nooo - don't look at their nighties!! that's so embarrassing! :P I hear their favorites have little pictures of ESR and RMS dueling with liitle swords.
Re: (Score:2)
Re: (Score:2)
How are we moving away from multithreaded? Most cpu can execute multiple threads at once. Not to mention that most OSes can efficiently schedule multiple threads across cores.