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

frist pst

[wzzzzrd]

ye

Re:frist pst

[Anonymous Coward]

Your first post looks to contain what looks like a disk, a black flap, and a scorpion.

SINGLE THREADED IS THE DOPE KING !!

[Anonymous Coward]

God save the Queen !!

You had me at..

[Sez Zero]

"memory savings".

Re:You had me at..

[Anonymous Coward]

You actually read the entire summary?!? Dude, I lost interest at "Javascript".

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

[Lisandro]

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

Yeah, it's not like it leaks memory like a BP pipeline.

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

[jellomizer]

However memory usage is one of those moot points.
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..

[Lisandro]

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:You had me at..

[Lumpy]

Then why does it suck horribly compared to Chrome?

Honestly, Chrome is 3X faster than Firefox. Plus I dont get chrome locking up right after I click on a download like Firefox does for 12-20 seconds.

Re:You had me at..

[mapkinase]

Me too. At first I was like "Yay!", then I said to myself: "let's wait and see".

Re:You had me at..

[bobcat7677]

I would like a non-PR answer to this question as well. Anybody???

Re:You had me at..

[Anonymous Coward]

You've got to be kidding, there's permanent defects in extensions like Firebug because they cannot shut off streaming because of a bug the FF team will not fix. These leak memory. I restarted FF yesterday it's already at 1GB on my work desktop. FF is a POS and most people wouldn't use it w/o the very useful extensions.

Re:You had me at..

[Joce640k]

Yeah, it's not like it leaks memory like a BP pipeline.

Used to.

So...can we put this cliche to bed now?

Re:You had me at..

[sirsnork]

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

[Anonymous Coward]

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

Re:You had me at..

[NatasRevol]

You want it to leak all over your bed??

Ewwww.

Re:You had me at..

[Enderandrew]

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

[ae1294]

Yeah, it's not like it leaks memory like a BP pipeline.

Used to.

So...can we put this cliche to bed now?

Not until they clean up all the residual memory!

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

[ae1294]

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:You had me at..

[Lisandro]

https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Firefox&content=leak&comments=0

Re:You had me at..

[Anonymous Coward]

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

[sourcerror]

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

[BlueStraggler]

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

[Anonymous Coward]

Not autimatically true. There have been tests that showed cases where it was to faster and/or more energy efficient to recalculate data than to reload them from cache or even worse main memory. Reason is the rising gap between advances in pure computing power and memory technology. Most programs are now memory bound instead of computation bound as it was in the last decades.

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

[Anonymous Coward]

327Mb with ONE tab and no extentions. Fuck off with the doesnt leak memory BS

Re:You had me at..

[Anonymous Coward]

Benchmarks don't cover certain real-world scenarios, e.g., four months of continuous usage without ever closing the browser window. Nobody does that with MSIE, for a variety of reasons (not least: people who use the web browser as a long-term task management system don't use MSIE, because it's not up to it). Chrome hasn't been mature enough to be used that way until rather recently (arguably: still isn't), so it doesn't tend to get used that way either. Firefox does -- and yeah, it does tend to accumulate memory footprint as the weeks go by (linearly with number of pages loaded, I think, or maybe linearly with the number of tabs opened, even after they've been long since closed). Eventually you have to restart it, just to reclaim the several gigabytes of memory it's not actually using any more. This is annoying, but it's only because we *have* a browser that *can* be used that heavily without crashing outright that we even notice it.

Re:You had me at..

[owlnation]

So...can we put this cliche to bed now?

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 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. They are already vain and arrogant about their lunatic version number race, so let's not go back to the days of them being in complete denial about other problems too. By not frequently reminding them about memory leaks, you are opening the door to yet more bloat going forward.

It's important they understand we have not forgotten how many years it took them to deal with the memory leaks they pretended did not even exist.

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

[Anonymous Coward]

Dude, FF9 with two tabs open and no plugins active: 400+ MB ram. This is 150 MB more than MS Access, Outlook, Word, Windows Explorer, and Dropbox, (all with active documents/data) combined. You've got to be from Mozilla. They're about the only people left in such denial about FF memory hogging.

Re:You had me at..

[hedwards]

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

[viperidaenz]

Yeah, I have 3 tabs open and its only consuming 127MB

Re:You had me at..

[squiggleslash]

Benchmarks are one thing, real life is another. I'm having to restart Firefox on a regular basis on my BRAND NEW EIGHT GIGABYTE LAPTOP. That's right:

• In an age in which 1G netbooks are extremely common, I have eight times as much memory
• It's a new laptop = fresh install of everything. The only thing carried over from my old machine was via Firefox Sync

So if you're about to whine "But Squiggy! It must be your profile! And you need to get with the program and have 4G of RAM", there's your answer. I don't want to hear it.

I really don't understand people like you who insist there isn't a problem when:

• There's a massive groundswell of frustration and anger about the issue
• Slashdot posts another "Mozilla reports - we found the problem! Next release will not have those memory problems!" article EVERY MONTH
• Usage of CHROME, which in every other respect is an inferior browser to Firefox, is going through the roof

You think we're making it up? You think everyone's just switching to Chrome for the hell of it? Clue: they're not switching because it's more compatible, or more user friendly, or has more features. Because nobody outside of a Google diehard would ever argue such a thing.

We use Firefox for a bit. Some time goes by. Maybe we launch another application. Perhaps we view a PDF. And then it starts. It takes a second or more for Firefox to notice we clicked on something. The scrollbar is no longer real time. Switching a tab causes nothing to happen for ten seconds. We try closing tabs. We go to "about:memory" and hit every button. It seems... slightly faster. Or was that our imagination? Hmmm, it's gone slow again.

I'm giving up. I downloaded Firefox 3.6 from Mozilla's website last night. I'm going to make it my default browser.

Re:You had me at..

[Anonymous Coward]

Sounds like you are looking at virtual memory i.e. mapped libs and shit that doesn't really use RAM?

Re:You had me at..

[Anonymous Coward]

Benchmarks are not representative of real world use. I haven't seen a single benchmark that left browsers open for weeks at a time, nor any that were opening and closes dozens of tabs within that time.

With a benchmark, you're trusting a group of people with a piece of software that is supposed to test everything in a 5 minute span of time. It doesn't work that way in real life.

Re:You had me at..

[Anthony Mouse]

Extensions can't be Firefox's killer feature if they make it eat all of your RAM.

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.

Of course, you've got to feel sorry for the poor bastard who still has a 2GHz Pentium 4 with less RAM than a Galaxy Tab.

Re:You had me at..

[Anonymous Coward]

Lynx?? Is that the new-fangled front end to wget?

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

[Anonymous Coward]

And we're on what now, Firefox 82?

Re:You had me at..

[Anonymous Coward]

There have been lots of documented cases and just as many egotistical Mozilla devs ready to bury the bug reports.

Firefox has had major memory leaks SINCE Firefox 2. Mozilla ADMITS all of that now because they realised continuing to push it off and call their users liars was bad for business.

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

[Anonymous Coward]

Yeah, it's not like it leaks memory like a BP pipeline.

Used to.

So...can we put this cliche to bed now?

Based on my anecdotal experience? No. Firefox routinely grows to over 1GB memory usage, and stays there even when I close all the tabs. It does so even with extensions disabled. It has done this in 3.x, 4.x, 5.x, 6.x, 7.x, and it still does it in 8.x. It does it in both Windows 7 and Ubuntu. Sorry, but I'm not ready to put this to rest. Some cliches are completely accurate and well deserved.

Re:You had me at..

[epine]

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.

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

[Anonymous Coward]

Mac, lol. Who gives a fuck?

Re:You had me at..

[Anonymous Coward]

It is attitudes like yours that causes all of the unnecessary bloat and slowness in software.

Re:You had me at..

[UnknownSoldier]

> 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:You had me at..

[MightyYar]

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:You had me at..

[Anonymous Coward]

So it's Firefox's fault that you're a sloppy programmer and can't unload your images manually?

Re:You had me at..

[MightyYar]

That is awesome - thanks. And I just read your team's memory presentation by Nicholas Nethercote :)

Re:You had me at..

[Anonymous Coward]

$97,000,000,000
+28% YOY sales growth .... ehhh, you're right. It's not worth worrying about, Firefox will soon be a footnote in the history of computing.

Re:You had me at..

[hazah]

It parses the HTML as a bonus!

Re:You had me at..

[Anonymous Coward]

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:You had me at..

[Anonymous Coward]

What are you babbling about? When you close the last tab in Chrome it closes the browser. That's not "crashing to desktop."

Re:You had me at..

[eexaa]

"Chrome is 3X faster"

Dear sir, how did you obtain such an accurate measurement?

Re:You had me at..

[Anonymous Coward]

I don't understand why you'd pick such a trivial nit as having to restart the browser once a day when there are far more substantial ones to pick at, in any browser of your choice. Hell, modern browsers restores just about all of their state when you restart. If losing a few seconds or a minute of time waiting for a browser to restart is appalling, then I daresay you should be happy that's the biggest problem you've found with the software.

We've become so damn spoiled by Firefox that we're all crybabies now about every imperfection it has.

Re:You had me at..

[garyebickford]

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:You had me at..

[Anonymous Coward]

Don't worry. They're not leaks unless you approve them.

Re:You had me at..

[Anonymous Coward]

Probably by accident. The latest Chromium release allows you to turn off plug-ins, and when Flash is turned off the page loads fine. So barring any compelling evidence to the contrary, I think Flash really is to blame.
Mind you, I like Firefox better and the only reason I'm not using it at the moment is because it stopped working on my computer. (Tried everything, including a full wipe and reinstall.) I'll try again in a year, unless the Chrome folks manage to do something about their utterly tasteless user interface. Seriously, the operating system provides all the functions you need to draw your interface, so why do it yourself? And if you do, why do it badly?

Re:You had me at..

[CCurzon]

Please cite a documented case that isn't caused by an extension.

As a tech, I know that, but as a user, I don't care about the difference. When my system slows to a crawl, my hard drive is thrashing and I look at task manager to see firefox.exe sitting at 250MB with two tabs open, there's a problem. I do have a few addons and having too many can cause problems but there comes a point when the host program needs to control the plugins and do something to keep from taking over.

Firefox is still my favourite browser for work and home, but the pauses and hangups when the memory consumption goes up get annoying.

Re:You had me at..

[Imbrondir]

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

[Anonymous Coward]

They run at about the same speed on my machine, except in artificial benchmarks or some apps with very intense DOM-manipulation.

If the downloading issue is your biggest speed-related beef then you seriously need to just use Chrome and stop trolling Firefox devs. And don't worry - once Chrome gets sufficiently complex and slow, there will be another ship for you to jump on.

Oh, and if you want a non-PR answer then don't ask such a stupid and baseless question as "why does it suck". I'm hardly a massive Firefox supporter, but this kind of childish bullshit has to stop.

Re:You had me at..

[M. Baranczak]

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 fact that it's 100% free software, unlike Chrome.

Re:You had me at..

[Just Some Guy]

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:You had me at..

[AmberBlackCat]

Which is why they always cream the competition in the benchmarks?

BWAHAHAHAHAHAHAHAHA

Re:You had me at..

[KiloByte]

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

[TheDarkMaster]

8GB of ram costs $50 on USA... Here is much, much more expensive.

Re:You had me at..

[hairyfeet]

" All go to hell except cave 76!" which is what i will open posts with when its obvious that we are dealing with "perception bubbles' which i was told is a nicer way of saying faboys. Do you HONESTLY think FF got its rep for being a memory hog by....what? Accident? maybe a conspiracy to promote chrome? Noooo...FF gots its WELL DESERVED memory piggie rep by leaking like a fricking sieve! Open up a dozen of the 'usual suspects" tabs, by that i mean yahoo/Gmail, FB, YouTube, all the usual places people go, look at how much memory its using, then leave it running overnight. Can't speak on the Linux version but I can say the windows version WILL be pounding the page file like a fat guy pounding cheeseburgers at the Mickey D's come the next day. they have gotten a LITTLE better between 8 and 9 but when it goes from slamming 100% CPU to 94% CPU on page load on nettops and it taking 12 hours instead of 8 to start pounding swap i don't really see a reason to cheer, do you?

And PLEASE do NOT trout out some benchmark or i'll be happy to post the benchmark that shows the Geforce FX is actually a decent DX9 chip, I can do that because when you write to the bench you can get them to say anything you want. What matters is real world usage on real world sites and frankly FF still isn't doing great there and hasn't since they came out with V4 which is why their numbers are falling. But you don't get a rep like FF has by accident friend, its not a conspiracy, its just reality. Maybe you are on Linux, i heard the Linux version is better on memory (or Linux don't let it pull that shit, one of the two) or maybe you have an Intel CPU as I've found unlike Chromium/QTWeb/Opera/Safari/IE that FF tends to favor Intel over AMD, who knows, but thousands of us having to use task manager to kill it because its sucked up all the resources and is beating the shit out of swap because we forgot and left it on overnight are not saying this to piss on your little FF flag. Kinda sad when i slap Dragon on my nephews boxes and a week later they are like "Thanks so much uncle, our machines are soooo fast now!" and the ONLY difference was swapping out FF for Dragon. hell when i did the same on my E-350 netbook I got nearly an hour of battery life simply because Dragon wasn't pounding the fuck out of CPU and RAM like FF.

If I had to guess personally i think its gecko. They didn't have this (well except for the memory leaks as its ALWAYS leaked) nearly as bad before chrome came out but it seems like trying to go "me too!" with Chrome has simply stretched the old gecko engine beyond what its capable of handling. Maybe they should switch to Webkit? Hell if i know but I do know I miss the old FF, it may have been a pig but its UI was nicer. I may not like the chrome UI that Dragon uses but at least in 10 versions since I've used it I've never had the resource usage go up, only down, and at least it doesn't kill my extensions. i hope they fix the mess and i try every new version but so far no joy, it still sucks on AMD and Windows.

Re:You had me at..

[Anonymous Coward]

My 4 computers. Every time I use them. Firefox has had huge memory leak problems since V1. They have been steadily getting better since version 3.4. It got worse when they started caching forward back results. I think this is still the issue, they don't clear when you close the tab. So over an extended browsing session, say using the same firefox instance for a few days of light use and egregious use of tabs, firefox will be pushing well over a gig with only one tab open to the google homepage.

It still very much has the same memory leak issues it had in V1.

Re:You had me at..

[Lisandro]

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

Much, much, much agreed. I like FF a lot, but refusing to address memory leaks at all just because "it's on the extensions" does nothing but to hurt the browser.

Re:You had me at..

[kbg]

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 groups, eye candy and rabid releases. Instead of focusing on creating solid, lean and fast browser that is massively tested.

It seems to me Firefox has turned itself into Netscape yet again

Re:You had me at..

[mcgrew]

Silverlight? I've only seen one site use that, and since it's a radio station, rather than install silverlight I just listen to one of the thousands of other radio stations that aren't so stupid that they use a platform that nobody has installed or uses.

I emailed them about it. I wasn't nice, either.

Re:You had me at..

[Anonymous Coward]

>Chrome is 3X faster than Firefox

Propaganda by an ad broker's fanboy. Liar. Get some decency.

Re:You had me at..

[Anonymous Coward]

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

Even still, they chose a poor data structure if it has any measurable effect on the operation of a browser.

Re:You had me at..

[Enderandrew]

Several in the subject cite the leaks only happen with certain extensions.

There was one that was vague that I tried to reproduce and couldn't, but the leak said it was on 5. It may have already been fixed.

Re:You had me at..

[Anonymous Coward]

Dude, why are you comparing a browser to every other application type except for other browsers?

Re:You had me at..

[Dog-Cow]

Chrome is not and has never been an MDI program. Virtually every Windows program exits when the last window is closed. (Some apps hide a window in the task bar.)

Really, you need to get out more.

Re:You had me at..

[Culture20]

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?

Re:You had me at..

[drinkypoo]

I will regularly have the same firefox process running for over a week on my XP machine (which, let's face it, is rarely up for longer than that.) Flash can crash and I can kill plugin-container and just keep going. And I only get to use 3 of my 8GB of RAM. You should maybe get less crappy extensions (I have several loaded, though, so it's not like any old extension will do that to you) or perhaps stop spending so much time on warez sites that try to root your system through your browser.

Chrome is just as bloaty as Firefox now from what I can tell. Lots of people have been complaining about its memory use in particular. Guess what? When you care about performance, you're going to use a bunch of memory. And yet I don't bother to close firefox before I play a game, though I do usually close all tabs but gmail.

Re:You had me at..

[Anonymous Coward]

I have noscript, adblock, ghostery, https everywhere, fasterfox, and tineye and my memory usage is at 240megabytes-ish. How is that in any way a problem? The laptop I got two years ago with 4gb of memory stock.

Re:You had me at..

[Anonymous Coward]

You can have it save your previous tabs upon closing, allowing you to not lose your nonsensical 150 tabs that you ABSOLUTELY NEED OPEN FOR 3 WEEKS AT A TIME!

PS, they're still clueless that the versioning gives away that they're spineless copycats.

Re:You had me at..

[bananaquackmoo]

I think you've explained it better than most. Firefox shouldn't be saying "we don't have memory leaks" they should be looking at the competition who doesn't have this problem.

Re:You had me at..

[camperslo]

An early MacBook with a Core Duo is IRC limited to 2 gig. Should someone need to upgrade just to run a browser? I would hope that a browser could get by alright on an older machine with 512 meg. Is there a really good reason why it shouldn't?

It seems that if a machine is getting old it may be time to stick a fork in it.

Re:You had me at..

[Cyphase]

It's not like it could have had you any later than that.

Re:You had me at..

[cyber-vandal]

I live in a world where spending $50 so that badly written software can run better isn't going to happen.

Re:You had me at..

[cyber-vandal]

Perhaps you missed the word combined.

Re:You had me at..

[MightyYar]

You are lucky - I recently got so fed up that I created a fresh profile and got rid of some of my favorite extensions. Currently only running Adblock+, NoScript, and Tree Style Tabs. I currently have a session that was opened this morning with 16 tabs (one of them about:memory). Memory usage is "376.66 MB (100.0%) -- explicit", "437.17 MB -- resident". I'm on a Mac, so I won't mention the vsize :)

Anyway, this is acceptable to me performance-wise, but I really miss my other extensions! When I'm in "developing web page" mode, I have to re-enable a bunch of them.

Oddly, some of them behave just fine on my PC running Windows XP at work.

Re:You had me at..

[MightyYar]

Annnnnnnddd... here comes the memory leaks. It's been 15 minutes since I posted my response. I've done some surfing around and closed up all of my tabs except for 4. All of those 4 were the same pages that were open when I wrote my original reply. Now in about:memory I see: "329.45 MB (100.0%) -- explicit", "504.09 MB -- resident"... and it keeps going up! By tomorrow morning, I'm sure I'll have to restart it because it will be at 750MB.

Re:You had me at..

[Anonymous Coward]

Perhaps Netscape/Mozilla/Firefox just needs to be renamed again, so people won't think the code is old and error-prone

Re:You had me at..

[qxcv]

I use ABP, Firebug, Vimperator, NoScript, HTTPS-Everywhere and Ghostery. I see no reason why ABP, HTTPS-Everywhere and Ghostery should not merge into a single extension (Ghostery and HTTPS-Everywhere are both privacy related, and if you're going to have two extensions like ABP and Ghostery that simply block tracking DOM elements they may as well be merged into one), and why the NoScript and Firebug features aren't already integrated into the browser (as they are with Webkit/Webkit DOM inspector and Chromium's easy "click-to-run-this-plugin" feature). With that many extensions (*all* being developed by different people), FF will almost certainly leak memory like a sieve.

Re:You had me at..

[Dwonis]

Netflix uses Silverlight.

Re:You had me at..

[smellotron]

We live in a world where 8GB of RAM costs $50.

There are smaller and more expensive parts of the memory hierarchy: if Firefox can single-handedly clobber the L3 cache on modern home PCs, then nothing on that system will run at "peak performance". Going in the other direction, if Firefox's virtual memory footprint spikes substantially, it will interfere with the OS's existing use of memory for caching. This can lead to sporadic disk access (paging) and a finger-pointing game between FF devs and OS devs.

My point is simple: memory footprint on a general-purpose machine always matters.

Re:You had me at..

[Anonymous Coward]

Clearly you didn't read the /. article from like 1-2 weeks ago which many conclusive answers and approaches to resolve the issue were provided.

Also, to note - this actual improvment is a conclusive answer to part of the problem..

so.. make sense troll?

Re:You had me at..

[Lumpy]

" you seriously need to just use Chrome and stop trolling Firefox devs."

it's bullshit like this that makes me stop submitting bug reports. Honestly if you guys stopped acting like holier than thou assholes people would actually help.

Nobody covers the problem that a person up top solved, that Firefox has a bug that remembers EVERY download even if you clear them in the window. So in order to fix that bug I need to uninstall Firefox, clean the registry, and install the latest version. A legitimate fix. When I ask why firefox locks up on downloads on the Firefox forums I get assholes like you.

Re:You had me at..

[Lumpy]

Javascript benchmarks.

Chrome is 3X faster than Firefox in javascript, what seems to be 70% of the freaking internet nowdays.

Re:You had me at..

[Mal-2]

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 what to use yet.

Re:You had me at..

[Anonymous Coward]

So that sounds like it's Flash's fault. You can set Chrome to block plugins by default, leaving a grey box that you can click to active the plugin (like NoScript / Flashblock do).

Re:You had me at..

[The End Of Days]

I know! I want my RAM to sit idle while I interact with my computer like it's 1978. I don't who these kids think they are, expecting their computers to do things.

Re:You had me at..

[Anonymous Coward]

What is to "chrase"?

Re:You had me at..

[bursch-X]

I've done tests over and over: Google Chrome is the very worst memory hog of the whole bunch. It always uses _at least_ around 1GB of RAM on OS X. That's ridiculous. Its WebKit brother Safari has a much smaller memory footprint, Firefox on OS X even more so (well it does have some performance issues and integration of OS X specific features sucks, but you can't have it all I guess).

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.

Re:You had me at..

[Anonymous Coward]

While we're playing the personal anecdote game, I have no such problems with Firefox on either my brand new 6GB home laptop, my newish 8GB work laptop, my even newer 16GB other work laptop, my old 2GB laptop, my previous 4GB work laptop, or, quite frankly, any machine I've run Firefox on since about version 3.

Re:You had me at..

[JonySuede]

What is your outlook version so that I request "downgrade" to it because my outlook takes 1.7Gb !
Firefox32 nightly only takes 147Mb with 3 tabs...

Re:You had me at..

[tibit]

You do care about memory usage, for a nefarious reason: garbage collection pauses scale with memory usage. Pretty much all Firefox "freezes" are garbage collection pauses. The cycle collector seems to be the worst offender, IIRC, it can take tens of seconds in pathological cases. Unfortunately we're not running Firefox on Azul Vega processors, it'd be a whole different ballgame then as the latter have hardware assist for garbage collection.

Re:You had me at..

[steelfood]

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 a way that the stuff he's not using any longer falls out of scope and can be picked up by the GC (for example, instantiating everything in main).

GC just makes it so that programmers don't have to explicitly manage their program's memory. But the programmer still has to understand memory management and design in such a way that the GC can do its intended work.

Re:You had me at..

[tibit]

In case of FF, it doesn't have that kind of memory leaks, or at least they'd be easy to fix. Those leaks are internal to FF and you couldn't control them from javascript. The problem it has is that it's very easy to inadvertently hold a reference that's not needed anymore -- said reference can easily hold up tens of megabytes of memory. A reference to anything within a DOM of a webpage requires holding up a whole compartment for that webpage. So you may think you're "just" holding a reference to a tiny part of a DOM, but it's really referencing everything else in that DOM due to the way a DOM is structured (a big tree). Heck, I haven't checked it but it may be that you only need a reference to a string within the DOM, not to any DOM node proper. A string itself doesn't reference anything else, but since it's within a compartment, the whole compartment will be held nevertheless. Someone who knows FF internals please correct me on that if I'm talking out of my ass.

Re:You had me at..

[Anonymous Coward]

I don't usually measure my laptop in gigabytes, but when I do, it's wholly inaccurate.

I have a three year old custom-built desktop with only 4 (four, half of your ram) GB of RAM and I never have trouble with Firefox, no restarts, no lag, no crashes.

You are probably using a Mac.

Re:You had me at..

[idbeholda]

And now they're going to pass the savings onto *YOU*!

Re:You had me at..

[siride]

Perhaps you've never looked at Chrome's memory usage...

Re:You had me at..

[Anonymous Coward]

and yet their browser uses 20MB+ memory to display my 1KB page (twenty thousands time more), on what is all that memory spent? (that is INCREMENTAL measure as in browser uses 70MB for some pages and i open this 1 more and its 90MB and page does not even use JS and just a bit of inline CSS).

Re:You had me at..

[DarkTempes]

The 3.6.x branch still gets (security) updates.

In all seriousness 3.6 is pretty rock solid about memory leaks, excluding some extensions of course.
I have around 15 extensions installed (not including plugins) and the only one that I've notice cause an active memory leak is firebug (and firebug is REALLY bad about it).
Otherwise I can leave 3.6.x running with a hundred tabs pretty much forever without seeing any serious memory increases (I can't remember the last time I saw it go over 400MB).

Now javascript performance and UI responsiveness? The later versions are definitely far better than 3.6 about those things.

Re:You had me at..

[voidphoenix]

+1. I'm running Nightly (v12.0a1). 1.2 GB memory in use, but that's >100 tabs and 28 enabled addons. Response is fine and only gets bad when I load pages that use flash. Flash sucks.
GPP, go update your browser to something less ancient.

Re:You had me at..

[evilviper]

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

That's usually exact opposite of reality, and yet far too many people believe it.

cache misses are extremely slow, and often it is faster to recompute values than to retrieve them from memory. Programmers often have wrong assumptions.

--Jimmy Gettys (2006): from the OLPC project

Re:You had me at..

[Anonymous Coward]

The Linux version leaks too. Or at least, it used to, the problem I've had seems to be fixed - or at least reduced a lot.

However, unlike many people here, I'm not claiming that just because I'm not hitting that leak anymore, there are no leaks. So far, nobody has been able to figure out what causes some people to hit the leaks, and others not to.

Re:You had me at..

[Anonymous Coward]

So, you're saying that leaking money is a good solution to leaking memory?

I've been adding memory to stop Firefox from causing my machine running out of memory. I'm currently up to 4 GB, most of which SITS UNUSED, except when that memory leak named Firefox is running. And you're suggesting the solution is to keep buying more memory...

Re:You had me at..

[xtracto]

Interesting that you note Nightly,

I was using Firefox NIghtly until about a week. The last update rendered the alpha program unusable (it experienced several second pauses, even when clicking on the menu bar). Now I am using the release version and everything is fine.

Re:You had me at..

[Anonymous Coward]

My FF 9 with 17 open tabs in two windows is using about 1.2 GB of virtual memory and between 810 and 747 MB of data memory. I'm checking it with top as I'm writing this and the fact it floats means it's actively garbage collecting (virtual memory changes accordingly). It doesn't feel like it slows down and I've only 4 GB of RAM. Not that bad IMHO.

I suggest you to stop using 3.6 anymore especially after all the work they've done on the JavaScript interpreter and the MemShrink initiative. We're at version 9 now, which could be 4.5 on the old numbering scheme and two years in the future (3.6 is from January 2010).

If what makes you stick on 3.6 is the new FF 4 GUI, there are ways to get the traditional one on new versions of FF. First of all, you can uncheck the Tab on top option and get the tabs between the menu and the html window (I did that). Then there are extensions to get back the status bar, but I realized the status bar is not that important: destination urls pop up at the bottom when you hover on links and the buttons of AdBlock, GreaseMonkey, Firebox etc show up at the right of the address bar now. Finally, on Linux you still get the File, Edit, View menu when it used to be. I don't know if it's possible to get it back on other platforms too but I understand the drive to save vertical space on the new reduced height screens of many laptops, so I won't bash Mozilla and the other browser teams for that.

Re:You had me at..

[jawtheshark]

Where is "here"? I just bought 16GB (4x4GB) of RAM for a new machine and it cost a whopping 61.82€. Sure it's "value RAM", but whatever... I've always been lucky with "value RAM". I order this stuff in Germany and not in my home country because my home country sucks for anything technological at reasonable prices.

Now, of course, this is modern DDR3 RAM and anything older you pay a premium. DDR2 and DDR RAM is more expensive per GB. That's why, for the last 5 years, I've always told: buy as much RAM as you can matching one of the following condition: a) can/are willing to afford or b) the machine accepts. When DDR4 (or whatever) becomes standard on desktop machines, expect a surge in price for DDR3.

Getting back to the 16GB RAM I just bought. The motherboard can accept 64GB RAM. Now, the price for 32GB would be around 220€ and for 64GB around 1036€. Either of those two options were a bit too much for my wallet, but it might be fully affordable in a few years. Unless a new RAM technology takes over, then the prices goes up again. Regardless, 16GB is plenty and the machine isn't going to be doing all that much.

Re:You had me at..

[jawtheshark]

Actually, many people have tried and 4GB works, but you only get 3.5GB because of chipset limitations. I've got a few machines like that. Not MacBooks, but just recently I had one of those early MacBooks on my workbench and I checked the possibility of upgrade online for that particular model. Official is 2GB, non-official 4GB.

It really is hit 'n miss. For example, the dumpster-sourced machine my sister uses based on a Intel D945CGCCR. According to the manual it supports 2GB. Yet, I found an older manual where it claims 4GB. This was corrected in a later manual. I suspect, that it's because the chipset doesn't allow more than 3.5GB even in 64-bit mode. (it's an E6600, it can do 64-bit). Online forums came to the consensus that 4GB works (again, with the 3.5GB limit).

My 2003 purchased AMD Athlon 2400+ MP on a Tyan Tiger 2466MPX also does this. 4GB allowed, but only 3.5GB usable *whatever you do*. As this isn't a 64-bit machine, you'd expect PAE to give you access to more. It doesn't, it is -again- a chipset limitation.

Also, older DDR1 latops are often rated 1GB... In all those I tried, replacing with 2x1GB instead of 2x512GB, worked just fine. You cannot be certain, of course, but by now I just have test modules lying around...

There is exactly one machine where I didn't manage to get it through the limit. It's a Fujitsu-Siemens Amilo Pa 1510. It's rated 2GB (DDR2) and it really doesn't want to do more. I tried 2x2GB with it (I had those lying around from another unfinished project), and it booted up with... 2.4GB. A bit more than the usual 1.8GB (~256MB for integrated graphics). So there was a win, but not really as much as a 2GB to 3.5GB upgrade.

Now, of course, I admit I'm at an advantage because I'm a dumpster diver and have parts lying around I can test before buying anything online. Still, check what is being said about such upgrades "on the street". A good starting point is here. Good luck.

Re:You had me at..

[Waccoon]

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.

• browser.sessionstore.interval = "300000"
• browser.sessionstore.max_tabs_undo = "0"
• browser.sessionstore.max_windows_undo = "0"

Naturally, this will remove the feature that restores your tabs in the event of a crash, but seeing how little Firefox blows up on me, this features is hardly useful, and certainly not worth the frustration of constant pauses and missed clicks. Firefox is now finally usable for everyday browsing.

Seriously, I've been hearing about this problem for years, and have been suffering with it since FF2, and nobody seems to have a clue what causes it. Personally, I thought it was a memory management issue. Turns out, it's just a bad design decision.

Re:You had me at..

[Anonymous Coward]

OT, but I couldn't help but think of the "Everybody's dead, Dave" routine from Red Dwarf whilst reading the 3rd paragraph of your post!

Re:You had me at..

[cadu]

Comments like this are what makes GREAT, STABLE and LEAN software keep being developed. Congratulations on the 'big shovel' philosophy!

Re:You had me at..

[TheDarkMaster]

"Here" is Brazil. To buy 16GB of RAM here, I need to spend more or less US$243. And it's important you know that the average salary here is much smaller than in the U.S. or Europe.

Re:You had me at..

[Xest]

That's great, it performs well in benchmarks.

But that doesn't change the fact literally thousands of people keep encountering problems of high memory usage in the real world with Firefox that goes way above and beyond that of other browsers.

Across many operating systems, on much different hardware, and with many configurations I've time and time again seen Firefox chewing silly amounts of RAM and grinding to a halt.

You can say it's fine in benchmarks, or you can say it's just me all you want - these are the usual responses from people on this sort of thing, but the fact is Firefox has lost a lot of users to Chrome etc. and the biggest complaint about Firefox is always it's high memory usage and the sluggishness this seems to introduce.

Denial of the problem isn't going to stop Firefox hemorrhaging users to the competition where users don't complain of these problems. Writing off anyone complaining as a troll is the surest way to condemn Firefox to history as an "also ran". I don't really see fanboyism when it comes to browser complaints, when people complain about a browser the complaint seems to just about always be genuine, so to give a fanboyist defensive reaction over it is just childish and silly.

Re:You had me at..

[jawtheshark]

Holy fuck... Want me to order RAM for you? I'm sure we can arrange something.

Re:You had me at..

[Joce640k]

How about you type "about:memory" in the URL bar and start sending the results to the devs. I'm sure they can point out what's causing your problem and you'l be helping millions of people.

Re:You had me at..

[AmiMoJo]

There needs to be a "use more memory" tick box in Firefox. You can increase the memory cache in about:config but it still seems to love paging out stuff so that switching tabs is slow. I have 16GB RAM, I want performance rather than low memory benchmark scores.

Re:You had me at..

[dargaud]

I have the latest 9.0.1 and it behaves exactly as he describes on all my systems (also 8Gb or RAM, different processors). With 100 tabs open I need to kill and restart about every 4 hours or it's not usable.

Re:You had me at..

[mikechant]

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.

Which Firefox version was this though? 'Last year' could mean anything from V3.6 to V9. FF JavaScript speed started to improve significantly at around V7 and by V9 the tests below show it as better than Chrome in 2 out of 3 standard tests (although you could call it a draw since it's still significantly slower in 1 out of the 3 tests).

http://www.anandtech.com/show/5260/firefox-9-released-brings-javascript-speed-improvements

Why don't you try your game again in V9 and report back?

Re:You had me at..

[bucky0]

I am *constantly* bringing electronics with me when I go to brazil for different people in my family. That electronics import duty is ridiculous.

Re:You had me at..

[voidphoenix]

I use Nightly for the native 64-bit build. Since it's in alpha, bugs are expected. I've run into some updates that make the browser completely unusable... at which point I revert to a previous build, report the bug (if it hasn't already been) and wait for an update. :D

Re:You had me at..

[dargaud]

Have you told firefox not to remember all your downloads indefinately?

I can see the option to clear recent history, and IIRC a max period for retaining the history in old versions, but I cannot find the setting right now. Where is it ?!?

Re:You had me at..

[mcgrew]

Well, their price changes last year and subsequent financial losses back up my point -- using silverlight to deliver content is stupid. No Netflix for me.

Re:You had me at..

[TheDarkMaster]

Of course I can buy RAM overseas like anyone. But when the shipment arrives at brazilian customs, the package is taxed in 60% or more. That and if package does not simply disappear in the customs.

Re:You had me at..

[TheDarkMaster]

Yep. And the customs many times uses assumed value, not the real value for the import duty calculation

Re:You had me at..

[ultranova]

Stop being a myopic PC developer with RAM means nothing -- there are other platforms where we actually care about RAM usage.

But you shouldn't except to be able to run PC programs on those platforms. It's not myopia to target the desktop rather than a netbook or an embedded device. After all, optimization requires developer time, which is not free, so sometimes the right choice is to let Moore's Law take care of it.

Re:You had me at..

[matunos]

Tell that to my consistently 2GB-hoarding Firefox process that grows overnight.

Re:You had me at..

[M. Baranczak]

Thanks for responding.

I can't remember what version I used at the time, probably 3.6, or whatever came right after that. I tried the game in FF 9, and it wouldn't work at all (possibly my fault, and I don't really have the time to debug it right now). But I tried the box2dweb demo, and it ran much better. There was none of the jerkiness I saw before.

So yeah, it did improve.

Re:You had me at..

[lennier]

And PLEASE do NOT trout out some benchmark

Sole true. Benchmarks are all red herrings. Whiting-wash, even. The manufacturers do it on porpoise.

Re:You had me at..

[Anonymous Coward]

Been there, done that. Mozilla denied any memory leak and closed the bug report promptly. Since then, I have removed Firefox from every computer my friends, family and myself own. I don't care enough about Firefox to file another report because I already have a solution in the form of a different, better browser.

Re:You had me at..

[Politas]

A tab is not a window.

Re:You had me at..

[camperslo]

Some of those not so old "slow" computers that were simply suffering from malware certainly are good candidates for recycling. It's always good to know just what some are capable of.

I was wondering if anyone would ever figure out how to modify the early Macbook fireware, as Apple had done with the Macbook Pros, to enable the SATA II 3 megbit/s data rate instead of the 1.5 megabit/s rate they supported out of the box.
It was after feedback from users that the Pros got the patch. Even at the lower rate the early machines were quite a bit faster with later/bigger/faster drives. Maybe someone can copy some code from the Pro firmware to unlock the dull potential of the ports in the Macbooks.

Re:You had me at..

[jawtheshark]

Some of those not so old "slow" computers that were simply suffering from malware certainly are good candidates for recycling. It's always good to know just what some are capable of.

That is exactly what my dumpster diving experience tells me, yes. Well, that and often not enough memory. The two older laptops I referred to came with 256MB RAM, respectively 512MB RAM. Both were very infected. Just upgrading the RAM to 2GB and reinstalling the machine gave capable machine on-par with current netbook offerings. One was even lower, I'd say: a P-IV 1.6GHz Mobile. It makes a damned fine email and surfing machine. I guess that even 1GB would have sufficed, but at the prices of RAM, why skimp?

I'm not familiar enough with MacBook (Pros) to talk about them. You never find those in dumpsters, but if I find one I'm surely going to take it... By now, I stopped bothering with anything lower than later AMD64 or Core (2) Duo. Sure, a good old P-IV does the trick, but I find nobody who takes them out of my hands, especially you get new machines (with warranty) for so cheap these days. Proof, I'm typing this on a consumer-end-router-sized Atom D525/2GB RAM/320GB HDD. Whopping 199€ and I could mount it behind my old LCD panel. Not a powerhouse, but space saving is worth something too and the monitor has a way better resolution than what most netbooks give you.

Re:You had me at..

[badkarmadayaccount]

You need GC and OS support for that. Hell, a properly done GC, with OS assistance should be all but invisible performance-wise.

Re:You had me at..

[tibit]

There is nothing that the OS can provide, really, that you can't do on the application level, as far as GC is concerned. Of course if you have anything concrete, please pitch in, but so far I can't really think of anything. I've just said that garbage collection is not invisible unless you have hardware assist: case in point is Firefox's garbage collection pauses, and there's not much you can do about those; they take cycles, they have to traverse a lot of memory. You can have javascript implementations that limit the amount of live memory, and limit garbage creation where they can, and thus you have javascript on Opera and in Safari -- it performs quite admirably compared to Firefox's, but that's because those implementations try hard to limit memory use. If their memory use would balloon to what's "normal" with leaky add-ins/extensions in Firefox, you'd be facing the same problem, they don't have access to some GC magic that Firefox wouldn't.

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

[Anonymous Coward]

Proactor pattern.

Re:SetTimeout

[drobety]

A plain time-ordered job queue?

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.

Re:SetTimeout

[Anonymous Coward]

$ man select

Synchronous I/O multiplexing existed before the web. Folks need to get caught up.

Re:SetTimeout

[Anonymous Coward]

That would mean that the number of ms you give it, is entierly pointless, since it won't care for it anway?

Somehow I can't see that, since it is unacceptable from a reliability standpoint. If I say 30 ms, it must run the thing in 30 ms. not in 200! Otherwise the whole animation fucks up.
And considering setInterval: What if the function takes longer than the interval? (Say you have GHC and LibreOffice compiling in the background ;) Will it skip one interval, causing the total count of executions to go haywire? Or will it execute it later? And if it does, what happens to the executions after that first late one?

The whole thing becomes a horrible mess.

So I think if anything, I expect the events to be driven in a thread sparks way.
Of course that may not yet have entered the backwards world of C-like languages...

But...

[Anonymous Coward]

Aren't single threaded programs bad?

Re:But...

[allcoolnameswheretak]

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

[HarrySquatter]

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

[msclrhd]

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

[0xABADC0DA]

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

[alexo]

http://www.gotw.ca/publications/concurrency-ddj.htm

Re:But...

[hedwards]

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

[Anonymous Coward]

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.

Re:But...

[DragonWriter]

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.

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 dynamically-typed languages like JavaScript.)

You correctly note that Java has a mechanism for managing this issue, but that doesn't have any real relation to static typing.

Re:But...

[Anonymous Coward]

SpiderMonkey originally had those optimizations. See the original post (which, for some reason, isn't linked in the summary: http://blog.mozilla.com/luke/2012/01/24/jsruntime-is-now-officially-single-threaded/). They were complex, though.

Re:But...

[ae1294]

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

[Anonymous Coward]

>Single threaded is the safest way to program

Especially given how crappy and fragile most web apps are. Sadly, people are far more forgiving to web apps when they hang, and lousy UIs, but expect far more from a standalone app. The attitude is usually, "well its a web app" as in what more do you expect from it?

Too bad rich UIs on the web didnt pan out due to high bandwidth demand in downloading the app and bloated crap Sun put out to be called later as Craplets.
Sadly, JavaScript took the spot due to bandwidth needs.

Re:But...

[superwiz]

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

[hedwards]

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

[hedwards]

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

[msclrhd]

That's too complex for me!

Re:But...

[sanosuke001]

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 can change but a cheap lock built into java. it isn't an initialization flag like volatile, final, or static, but a block like if, else, or try and everything inside the block is synchronized on the object in question ie. synchronized(this) { // stuff }. This CAN be a flag on a method like 'public synchronized void doStuff() { // stuff }' but that's really the same as 'public void doStuff() { synchronized(this) { // stuff } }'. you need to synchronize on an object that won't go away or be null ('this' usually works okay) and if you use something else, you can get warnings for not synchronizing when it is accessed but it won't stop you from doing so. You could be a horrible programmer and forget to synchronize and still break everything; java won't necessarily care.

Maybe I misunderstood your meaning, but if not, I hope I explained it well.

Re:But...

[19thNervousBreakdown]

Oh, get real.

Re:But...

[Dog-Cow]

it needs to lock the lock as well so other threads know to wait.

So, it's locks all the way down?

Re:But...

[ae1294]

Oh, get real.

Lets END this before it starts.

Re:But...

[Anonymous Coward]

NaN!

Re:But...

[sanosuke001]

Well, it locks during whatever it does. It can cause deadlocks, yes, if something it calls itself also tries to access the same lock.

Re:But...

[shutdown -p now]

in particular, statically typed languages which allow arbitrary pointer manipulation -- like C/C++ -- have this problem just as much as dynamically-typed languages like JavaScript.

Thing is, C++ doesn't have mutable vtables (you can roll your own, but the standard ones are not; whereas in JS, you effectively have mutable per-object "vtables").

Re:But...

[Anonymous Coward]

"any other thing that can be changed dynamically could be changed at runtime by another thread."
What kinds of application level objects need synchronous access (does that include atomic reference swaps)?

Re:But...

[toddestan]

On a core-by-core basis, my AMD Phenom II system is about 60% faster than the old Athlon XP system it replaced in terms of GFLOPs. The main speed boost is from the Phenom II system having six cores versus the old single core computer. Now that you mention it, the new system is also about 60% faster by clock speed (2.0 vs 3.3 Ghz) though AMD did rate the old chip as a "3000+" which means at the time they thought it performed like a 3GHz chip. So in some ways the main advancement over a period of about 7 years was to figure out how to cram 600% more cores in the same space with only about a 50% rise in power usage, though that isn't really fair as that is ignoring a lot of other stuff like 64-bit.

Re:But...

[allcoolnameswheretak]

Freezing UI does sound alot like a threading problem. I'm not sure what language and tools you're using, but you might want to google "Swing single thread rule" and read into the results to learn alot about the problem of multithreading UI's. Most of the results will be Java specific, but I'm sure they also apply to other technologies.

Oh noes!

[Alex Belits]

The great technology inspired by illustrous Windows developers building the whole applications as everything-should-access-everything model, was abandoned!

Re:Oh noes!

[superwiz]

Not sure why this was modded down. Windows WAS the system in which tread paradigm dominated. It was a performance gain in a single processor machine. Now that we are moving away from multi-threaded and towards multi-core, I guess most people forget what one has to do with the other.

Re:Oh noes!

[HarrySquatter]

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.

Re:Oh noes!

[Anonymous Coward]

Windows WAS the system in which tread paradigm dominated. It was a performance gain in a single processor machine.

For the simple reason of heavier processes and not because of the everything-should-access-everything model. Decisions, decisions, decisions as somebody would say and throw a selection of fine chairs out of the office windows.

Re:Oh noes!

[superwiz]

there is a lesser performance gain in using threads instead of processes on multi-core systems. since the cost of using threads is less isolation of memory space, it is by definition less robust. the move back to processes is picking up because of just this. the price/reward scale is beginning to tip in the other direction.

us to hoist a lot data currently

[ShakaUVM]

"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

[Anonymous Coward]

https://bugzilla.mozilla.org/show_bug.cgi?id=720753#c0

Re:us to hoist a lot data currently

[Locutus]

yeah, why have multi-threading when you can just use different processors to keep applications responsive. Sounds like a cop out due to poor implementations to me. And lets stop running more than one application at a time since we can run our OS and app in virtual machines while we're at it.

LoB

Re:us to hoist a lot data currently

[Anonymous Coward]

This is what it sounds like to me:

If you have a binder full of pages, each one can be pulled out, so it may have to have some copyright information on each page. But if you've binded the book together more rigorously, as with string and glue, you can move the copyright information to one particular place and let the pages share it.

Re:us to hoist a lot data currently

[Anonymous Coward]

Because as I read the architecture, the "web worker" already runs the javascript as a separate background process from the HTML page. Why multithread something that is already running as a separate process?

Re:us to hoist a lot data currently

[PhrostyMcByte]

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 instead of native threads, though that brings along its own bag of complexities.

Re:us to hoist a lot data currently

[Locutus]

ah, so the "web worker" implementation from HTML5 does a better job for threading in Javascript. got it. If that's what developers find easier and better to use then it makes sense to simplify the threading in their own runtime. Being a published standard helps too so I get it now.

LoB

Re:us to hoist a lot data currently

[superwiz]

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 switch to change from blocking to the running thread (because the the running one is running on another core). And you will still pay the performance hit for switching context, because your 1st core now has to run a thread from a different process. Given that writing everything in multi-threadead paradigm requires more complex memory management, it doesn't make sense to do it anymore: there are fewer performance gains from it and there is a higher frequency of bugs due to code complexity.

Re:us to hoist a lot data currently

[lgw]

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 asynchronous programming any more (heck, most programmers can't get threads right), and I like being able to do 100s of parallel blocking operations without the complexity of serializing stuff to hand between processes.

Re:us to hoist a lot data currently

[bradleyjg]

It is a somewhat jargon-y term used by compiler programmers to refer to pulling functions or values up into a wider scope. Often this means that the compiler can optimize away many duplicates of the same function or value.

Re:us to hoist a lot data currently

[Locutus]

there were many reasons for threading, like it was cheaper to create a thread and use in-process communications between the main process and the threads than it was to fork another process and duplicate the entire process and use other IPC mechanism for comms. But I think that's become less of an expense with modern CPUs. Threading was a mainstay of OS/2 in the early 90s and it resulted in amazing sense of responsiveness on even low end hardware. Windows9x sucked at threading and NT was a dog too but they won and their developers mostly stuck with not using threading. Even much of the NT System apps/utils through XP were not well threaded and I doubt Vista nor Windows 7 are any better.

Besides, HTML 5 specs the "web workers" for threading so if there's a standard being followed there is less of a need to have the JavaScript engine providing the user threading. This now seems like the right move since we've seen browsers going to isolating tabs/pages in their own process so shrinking what's run in those processes would be desirable as long as capabilities(web worksers) remain.

LoB

Re:us to hoist a lot data currently

[superwiz]

But you can fork and exec and let your processes block just as well as you let your threads blocks. The serialization between processes should be less sophisticated than it is between threads because if one process blows up, it doesn't take all the others with it.

Re:us to hoist a lot data currently

[superwiz]

yes, and the reason it was cheaper was because the threads would run on the same processor. and blocking in a process meant that you'd have to go through a context switch before another process would run. essentially that meant that any ipc would have to wait for a context switch to happen. but with multiple threads/processes running on multiple cores, it doesn't matter how your two threads communicate (as IPCs or through common memory space). fork and exec doesn't duplicate the whole process. only dirtied blocks get duplicated. which means the code blocks do not.

Re:us to hoist a lot data currently

[Thiez]

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

Can you provide a source for that? Because as far as I'm aware cores can pretty much decide to perform stores in any order and at any time they like, and memory is only shared in the lowest layer of cache (usually L3). If what you say is true, it would kind of defeat the purpose of instructions such as http://siyobik.info/main/reference/instruction/MFENCE this.

Re:us to hoist a lot data currently

[lgw]

I think that's backwards. Between threads I can just pass a pointer/reference - it's seamless and easy. Between processes I have to put a lot of work into serializing my object (which can get annyoingly complicated if my object is a fraph that might have cycles) just to hand it from one process to another.

I prefer a model where each pocess is a thread pool where all the threads are doing the same task - so it's the same bug regardless of which thread - letting my tune the nuber of threads that make sense for each task. But that's only practical if your shop has a powerful toolchain to make work of serialization vanish (this is one of Googles big advantages). My current shop doesn't, so despite the problems inherent in a process with hundreds of threads, it's still easier than doing it the "right" way, even with the occasional hair-pulling threading bug.

Re:us to hoist a lot data currently

[lennier]

"us to hoist a lot data currently stored"

I really wish I knew what this phrase meant. It sounds fascinating.

I believe it involves repeated self-application of the Petard pattern.

Re:us to hoist a lot data currently

[superwiz]

Between threads I can just pass a pointer/reference - it's seamless and easy. Between processes I have to put a lot of work into serializing my object (which can get annyoingly complicated if my object is a fraph that might have cycles) just to hand it from one process to another.

Look into shared memory, or even a memory-mapped file. Memory-mapped files, by the way, are just as efficient as shared memory. What happens underneath is "memory" is physical memory pages+disk swap, while "memory mapped file" is disk file+in-memory cache. But since these are both operating-system level constructs, they can be shared between processes. You don't have to serialize objects between processes. Use IPCs.

Re:us to hoist a lot data currently

[lgw]

It's not so much about processor efficiency, but dev time. IPCs all require the same heavy workload in some fashion - from COM IDLs to RESTful stuff, you have to tell the library *how* to serialize your objects, and that can be a real pain (again, unless there's a company-wide mandate to use a specific good toolchain for all objects definitions, like Google does with protobuffers). Especially if you have a ton of legacy code, you never know what problems you'll hit until you hit them.

Sure, greenfield coding, I'd just use protobuffers and be happy with lots of processes, but I don't see any point in my career where I'd get to do that. Maybe after I retire, if I start some open source project ...

Re:us to hoist a lot data currently

[superwiz]

No, not IDL. If it requires serialization, it's not an IPC. You use shared memory mmapped files as you would regular memory. It is, in fact, not just in name memory shared between processes the way it would be shared between threads. Only the pointer has a different value in processes and the same value in threads.

Re:us to hoist a lot data currently

[Anonymous Coward]

Can you provide a source for that?

The parent speaks of standard cache coherency protocols as if they would be special to x86 and references to user level threads as if they would be fundamentally different from the data sharing perspective. In conclusion, I would say that I dunno.

God saves his son 1st, Jesuchrist.

[Anonymous Coward]

God save the Queen !!

It's an evil sentence for saving the tiranny originated by the supposed saved Queen, so many believers of this simple statement are simply fooled. Why to believe in their damn words instead of saving themselves?

For religion, the more correct statement should be: God saves his dear son 1st, Jesuchrist..

The Javascript Engine is single threaded because when it is in the client-side, the client-side's process is supposed to be a single thread. The issue is totally different when the Javascript Engine is used in the server-side that almost processes of many web servers are concurrent (aka multi-threaded).

Javascript is not a CPU-powerful language, so it's better to re-design the language (or to create one new) and its paradigm (e.g. instead of slot-based, untyped and single threaded, it should class-based, typed and multi-threaded) for gaining something luxurious of CPU performance and to be lesser memory-hog.

JCPM

Re:God saves his son 1st, Jesuchrist.

[K. S. Kyosuke]

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:God saves his son 1st, Jesuchrist.

[Anonymous Coward]

You're insensitive clod that did this weird question.

Why should UK be exclusively the interested country for God?.

I said that above statement was evil, not the country.

And for our goodness, God is our transcendental entity for all us that respect the goodness, and we don't commit bloody evilnesses.

God is not limited to an only country for its own interests.

"God save the Queen" and "God bless America" are wrongful statements that God shouldn't hear them as valid in its glorified kingdom that's not here on this world. Damn the sinners who collaborated the promotion of these statements for their particular interests.

JCPM

Re:God saves his son 1st, Jesuchrist.

[viperidaenz]

class-based, typed and multi-threaded

You mean... Java?

Re:God saves his son 1st, Jesuchrist.

[Anonymous Coward]

Yay, a functionally illiterate Bible thumper! Stick around and troll some more -- I wanna see you square off against APK.

They're supposed to be prayers for the welfare of the Queen and America, respectively. Are you saying we shouldn't pray for the welfare of any earthly entity?

Re:God saves his son 1st, Jesuchrist.

[Anonymous Coward]

Yay, a functionally illiterate Bible thumper! Stick around and troll some more -- I wanna see you square off against APK.

Don't be silly, it is APK.

Re:God saves his son 1st, Jesuchrist.

[Anonymous Coward]

Look here. I know you're insane and all, or that I'm feeding a troll who's acting insane, but "God save the Queen" and "God bless America" are prayers, phrases of request: (God, please save the queen; God, please bless america), not statements of unilateral fact with exclusivity (God saves the Queen, but not you lowly peasants; God blesses America to the exclusion of all other countries!).

At least get it right.

JCPM's educator

  PS

Slow Down Cowboy!

Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 1 hour, 41 minutes since you last successfully posted a comment

Really? How long do I have to wait now? 2 hours? 5 minutes is a deterrant. 2 hours means I shift to another IP. *ssholes

Re:God saves his son 1st, Jesuchrist.

[Anonymous Coward]

Ago days, i had haven a dream when i was sleeping:

I've seen a crown of cream and liquid strawberry lollipops (corona de chupachups de nata y fresa liquida) after of the resulting nuclear detonation, possibly in the land of Canaaan, and two important electro-executed but living witnesses were kneeling themselves to said crown.

After, a small flying spacecraft (of the size of a kitchen's plate) did signal us to following it as our ordered guide. And we did walk as on the garden's road ...

JCPM: i don't question what another prayers should do. They should take wisely their own decisions when they were praising.

Re:God saves his son 1st, Jesuchrist.

[TheCouchPotatoFamine]

Eliza? Is that you?

Re:God saves his son 1st, Jesuchrist.

[Anonymous Coward]

EAt my ballz you niggercunt . That's right, I fucking said niggercunt . Downmod me your fucking splashdot idiot fuckface free-speech-hating hypocryte nazi niggercunts !

Oh, I know this one!

[Anonymous Coward]

Horribly.

However, 10+ Years After 64-Bit

[feuertod]

Operating systems were widely available, Firefox has still failed to make a 64-bit dist

Re:However, 10+ Years After 64-Bit

[ilikenwf]

Not really, take a look at the nighties. They just don't officially support it because of the trouble that can happen dealing with browser plugins on windows.

Re:However, 10+ Years After 64-Bit

[hedwards]

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:However, 10+ Years After 64-Bit

[Anonymous Coward]

Why complain over the lack of 64bit? What benefit would making it 64-bit give it? Access to more memory . . no thanks. Sure the wow overhead eats a bit, but 64bit would only improve how much memory that application can access.

I would much rather their devel time go towards making all plugings and javascript run in a separate jailed thread where if they misbehave they are easily killed and their effects are limited.

Re:However, 10+ Years After 64-Bit

[Jeng]

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:However, 10+ Years After 64-Bit

[loufoque]

The AMD64 instruction set and the ABI are so much better than on i386/i686 that you definitely should.

Re:However, 10+ Years After 64-Bit

[Anonymous Coward]

It's the same reason your mom goes to Tyrone to get fucked by his 10-inch black dick over your dad's 2 incher.

Re:However, 10+ Years After 64-Bit

[lgw]

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 about in a given funtion fits in the register set.

It's also the case that the most likey reason any given C/C++ code was late to the 64-bit bit was that it was such crap code that it couldn't be "ported", where well-written code would just build 64-bit with minor fixes. Not directly applicable to FF, but there's a general reason people came to look down on code that couldn't make the jump.

Re:However, 10+ Years After 64-Bit

[Anonymous Coward]

Just because you have 64-bits doesn't mean you have to use them for everything.

Yeah, but that's a broad statement fixated on memory optimization. Programmers sometimes jump through hurdles (ouch) to make values fit nicely in 32 bits or less - and it complicates the code in ways that aren't helpful. So, I'd consider sometimes wasting memory the lesser of two evils, especially since having more memory is a 64-bit perk and with the source code it's easier to remedy wasted memory in less time than split-up obfuscated expressions.

I'm not really sure why they would go and undo all that just to use 64bits.

Generally, I laud 64-bit architectures because of experience and hindsight. Recently I wrote an algorithm (in C, not ...) to very quickly process a binary stream and there were many points where I had to optimize the code by splitting the buffer into two separately handled 32-bit integers, because the bitshifts were significantly faster that way. Because of that, there were many hideous expressions (even for bitwise ops) and more time spent debugging.

For highest performance it was necessary on a 32-bit processor, but there wouldn't have been a penalty for using 64 bit operations on a 64-bit processor (except memory bandwidth when swapping from registers).

And likewise, mixing types in an expression steals performance to save memory (...mixed 8/16/32 types in an expression go through conversion to the largest type when evaluated - the conversion overhead becomes apparent in loops)... But, that's crazy talk and I must go put the leaches on myself now...

S:P ~(i wont unroll loops, i wont unroll loops, ...)

Re:However, 10+ Years After 64-Bit

[garyebickford]

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:However, 10+ Years After 64-Bit

[the linux geek]

But with the added perk of increased cache footprint.

Re:However, 10+ Years After 64-Bit

[loufoque]

You have twice as many registers, which are each twice as big.
Spilling to memory is much more costly than a cache miss.

Re:However, 10+ Years After 64-Bit

[loufoque]

Sorry, I meant to say more *critical*, not more *costly*.

(When will we be able to edit our posts?)

Re:However, 10+ Years After 64-Bit

[mister_playboy]

It's not Firefox's fault that you choose to use an "64-bit" OS where 95% of the programs happend to be 32 bit. (i.e. Windows) Try running IE in 64-bit mode and see how many things won't work.

I looked at the Programs Folders sizes on a Win 7 64-bit machine recently:

Program Files : 819MB
Program Files (x86) : 40.43GB

Windows is still a very long way from allowing you to run a full 64-bit enviroment, but you can do that today on Linux if you like.

I am confusedf

[Anonymous Coward]

Wait, I thought that the goal all along was to move AWAY from the Giant Single Thread of Javascript model?

Oh.

I see what you did there.

Can't tell if trolling or serious

[Gazzonyx]

The sad thing is that patterns have become so many and so complicated that I can't tell if you're joking or not. Proactor pattern? Is that really a thing?

Re:Can't tell if trolling or serious

[Alex Belits]

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:Can't tell if trolling or serious

[nschubach]

Yeah ... http://en.wikipedia.org/wiki/Proactor_pattern

What about Add-ons / Extensions?

[Anonymous Coward]

Firefox Add-Ons (well, at least Extensions) are JavaScript code and chrome directives. Will these get a separate thread?

Re:What about Add-ons / Extensions?

[Anonymous Coward]

No, they will get a separate PROCESS, why would they need a thread?

How hard is it to understand? Multiple processes, each with multiple thread support, but generally only one actual thread executing, is ugly and failhappy. Multiple processes, each with a single thread, is simple and clean -- and does the same damn thing.

You need a VP

[Anonymous Coward]

I really wish I knew what this phrase meant

You need to talk to the Executive Vice President of Sales and Marketing. Call for an appointment.

A mistake

[claytongulick]

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

[Anonymous Coward]

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.

Citation needed.

It sounds to me that your suggestion is not something that you graft on to an existing multi-threaded implementation.

Probably would be the same as ripping/replacing existing code, and then designing it properly.

They've done the rip/replace.

Re:A mistake

[Anonymous Coward]

There is no reason why you can't implement map/reduce across multiple web-workers. You don't need promiscuous threading for that algorithm, in fact, it was explicitly designed to work in a shared-nothing environment.

In fact, I am currently working on a highly-parallel tree searching algorithm written with Mozilla's engine, and I am really looking forward to these changes: reduced memory footprint and faster-running code is ALWAYS beneficial. The fact that I have to decide how to parallelize my algorithm, instead of hoping the JS interpreter magically figures it out for me, is not a problem.

Re:A mistake

[msclrhd]

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:A mistake

[Xanny]

I'd call it a mistake just because they are dodging the bullet on parallel computing. Javascript is becoming a general purpose application architecture on the user side, except you have to use tricks to get multithread support. Either do the hard work to make JS work in parallel or give an alternative scripting language that uses static typing and a standard stack so we can easily mutlithread it for more computationally intensive web apps.

Re:A mistake

[Anonymous Coward]

There are many ways to write parallel programs. The architecture they are proposing is that every JS process/thread/runtime/whatever is share nothing. Rather than trying to "find" parallism in the code, you instead just create another JS process (like a WebWorker) and communicate with it via message passing instead of direct object access and locking. Does this sound like the architecture of other parallel languages eg Erlang and Google Dart? The Erlang runtime can do interesting optimizations since objects are immutable so the runtime can treat everything as a closure. However, this difference aside, the way in which you write parallel code in that paradigm is via isolated processes and message passing.

Looking at other problems like errant JS processes; think about how much simpler it is to isolate and kill them when something goes wrong if it has no shared state with other processes. Scaling up the thought, how does Chrome work? Rather than try to have a lot of shared objects, they scaled down the base runtime and made each tab a full blow process. I would argue strongly, that the Mozilla team is on the right path with shared-nothing message based parallelism; just look at Chrome.

Re:A mistake

[dodobh]

Given that web workers essentially are a fork(), you can just use standard Unix style IPC with message passing instead of the complexity of shared memory.

Re:A mistake

[claytongulick]

I think you really nailed my point, and more succinctly.

The other replies to my post are rushing to point out that I can still use web workers with map/reduce to achieve the same effect.

While those other posters are correct, my point is that this should be baked in to the language. I agree with you, they are basically dodging the bullet here.

I've felt like javascript has huge potential to be the Next Big Thing(tm) in parallel computing because it is already so inherently asynchronous and functional.

I'd like to see them do the sorts of things Microsoft is doing with c# - things like Parallel.ForEach, but transparent.

Something like:
[parallel(threads=5)]
{
    { firstName="clay", lastName="gulick"},
    { firstName="clay", lastName="gulick"},
    { firstName="clay", lastName="gulick"},
}.each(function(item) { ... });

Re:A mistake

[Anonymous Coward]

The easy parallelization you describe is a theoretical possibility in pure functional languages. We're talking Haskell-style "no such thing as a variable" purity here. Want to learn about monads? Be my guest, but 99.9999% of Javascript programmers just want to be able to say "x += 1".

Javascript has side-effects, so you can't simply say "that's a map, let's parallelize it". The mapping function might do something that would affect other calls, so you have to do it in serial.

So, no, removing threading from their JS engine is not depriving you of a trivial optimization.

Re:A mistake

[Dwonis]

Part of the problem is that the Javascript programming model is inherently single-threaded, so even if your Javascript engine is multi-threaded, it must fake being single-threaded. It could be that it makes more sense to just use a single-threaded Javascript engine.

Re:A mistake

[Anonymous Coward]

I would personally love a way to block the current Javascript thread, spawn a new thread, and wait until the new thread terminates before resuming the original thread from the point where it had been.

You're essentially building a state machine. Context (as in, which code block you are executing) is part of state. But since Javascript is purely event-driven, to truly build a state machine in Javascript you are forced to use a bunch of global variables. This is... wrong.

There are 3 ways to block the current thread's execution without (a) pegging a core, (b) losing state, and (c) simultaneously halting all other Javascript on the page, thereby preventing the user from providing the desired input:

1. alert(), prompt(), confirm() - not terribly versatile. May not even be a movable popup (Firefox), obscuring part of the page.

2. showModalDialog() - much more versatile than the previous, but also likely to be blocked by a popup blocker. The user can't interact with the original page, but can see it (by moving the dialog) and can interact with the user interface presented in the dialog window.

3. exit the current function and wait for the desired event to be fired (via user interaction). Exiting the current function, of course, requires a loss of state (and the return stack may be several layers deep), so you will have to manually save state and have some way to resume execution at the desired point after the user has provided the needed input. Whether that means every function is atomic and the event triggers a subsequent function, or whether that means skipping the portion of the function that was already executed and resuming at the point where it left off.

Of those options, 3 is obviously the most versatile, but it's also a lot more work.

Welcome to the Jungle

[Anonymous Coward]

" With so much happening in the computing world, now seemed like the right time to write "Welcome to the Jungle" - a sequel to my earlier "The Free Lunch Is Over" essay. "

Re:Welcome to the Jungle

[Mal-2]

Multi-core at least lets you get the housekeeping and low-demand applications out of the way so your compute-intensive app can have one or two cores all to itself. They may not be that much (or ANY) faster than the cores of yesteryear, but at least you know you can have 100% of one or two. This, and a reduction in the number of context-switching penalties incurred, helps keep things SMOOTH, if not necessarily that much faster. True number crunchers should be prepared to farm their work out across as many cores as they can reach.

Release..

[mrops]

So then, we will have this released, say ummmm.... 2 hours from now.

Sleeping tabs

[anyanka]

Sounds good to me. Multi-threaded synchronization is notoriously hard to get right, so why risk it unless you *really* need the multicore performance?

And the thing with browsers isn't that they need access to more resources – they should have *less* resources (CPU, memory) and use them better. I'm not particularly happy with dedicating 25% of a CPU just to have a browser window with some tabs open while I'm working on something else – particularly not while I'm on battery. Why can't I get Firefox (and/or Chromium) to suspend the JS engine and any plugins on tabs that aren't visible anyway? Yes I know that you *sometimes* want to listen to audio from another tab, but most of the time even that is just annoying.

Oh, and just sandbox the damn stuff, and get rid og 93% of the possible security issues...

But am I annoyed enough to file wishlists in Bugzilla or start writing patches? Not really, but that's possibly because I believe complaining on Slashdot should be more than enough to get things fixed.

Re:Sleeping tabs

[Anonymous Coward]

Oh, and just sandbox the damn stuff, and get rid og 93% of the possible security issues...

I'm calling bullshit on that statistic

Re:Sleeping tabs

[Lennie]

Actually, without the synchronization I would expect it to work better on multicore.

Backwards, but ok....

[medv4380]

I don't like this because it's clearly a step backwards. Yes, Shared Nothing does work but it puts a limit on how many cores you can ultimately use. You won't get speedups from processors with more and more cores.

I'll agree that it's a pain to try and make good parallel/concurrent code work. I've seen too many cases of we'll optimize with this parallel algorithm, but it only is faster in extream cases like sorting 100,000 items. I rarely need to sort anything like a 1000 items in a web page so I'd rarely use a parallel sort like that, but what they are doing sounds more like giving up rather then continuing to search for an answer for using multiple cores long term.

Just what are we going to do when we have 32 cores? Most apps I've worked on couldn't be separated into 32 separate shared nothing tasks, but I might have a couple loops that could be partitioned into N tasks.

Re:Backwards, but ok....

[Zan Lynx]

You'll be reading 32 web pages at the same time with your 32 cores.

And some of those web pages will be using Javascript worker threads to run the AI logic for the HTML5 WebGL first person shooter you're playing.

Re:Backwards, but ok....

[bucky0]

Yes, Shared Nothing does work but it puts a limit on how many cores you can ultimately use. You won't get speedups from processors with more and more cores.

Nope. You got that exactly backwards. As the number of parallel tasks increases, synchronizing shared resources (and other communication in general) starts to dominate the decrease in efficiency. Look at erlang and its ability to run (and keep fed) 10's of thousands of threads simultaneously.

Your example of partitioning a loop into N tasks is exactly mappable to a shared-nothing architechture (assuming there is nothing that needs to be shared between separate iterations of the loop)

server-side

[Anonymous Coward]

So much for server-side javascript, where you actually need threads like nothing else.

Re:server-side

[Lennie]

This doesn't make the process single threaded, just the runtime within the engine.

Re:angry

[TaoPhoenix]

So wait, if you run that in Songbird Browser does it become an Angry Bird? : )

OM NOM NOM!

[zooblethorpe]

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!

[Zan Lynx]

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:OM NOM NOM!

[Anonymous Coward]

Cho' Gath has ended another champion.

Re:OM NOM NOM!

[Anonymous Coward]

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.

Re:OM NOM NOM!

[zooblethorpe]

Interesting comparison. Process Explorer right now shows 1.06 GB virtual, 885 MB private. If memory serves, their "private bytes" = actual memory. The numbers were higher when I posted earlier.

Thanks for about:memory, I didn't know that one. That shows different numbers, including:

799.88 MB -- private
690.46 MB -- resident
1,033.78 MB -- vsize

The differences between what the OS reports and what FF itself reports are interesting. Any ideas why?

Cheers,

Re:OM NOM NOM!

[Pathwalker]

My guess would be memory fragmentation; Firefox requests and releases pools of memory from the OS rather than making OS level requests every time it needs memory, and unless a pool is completely unused, it can't be released.

So there is some additional overhead of space that is free for use by new internal requests, but can not be released back to the OS.

Re:OM NOM NOM!

[smellotron]

My first guess about the discrepancy would be whether K=1024 or K=1000.. but generously, that puts FF's 799.88 MB private memory (K=1024) at 817.76 MB private memory (K=1000), leaving ~7% unaccounted still. Maybe FF is ignoring stack space, which AFAIK is a fixed size per-thread and may not be easy to measure (heap space can be measured trivially by instrumenting malloc).

Regarding the definition of various memory segments: "private" refers to pages in the virtual memory space that are not shared by any other processes. "vsize" refers to both private and shared pages in the virtual memory space, but shared pages should not be double-counted from multiple processes (i.e. in Internet Explorer, the bulk of the memory footprint is pages shared with the OS, thus the marginal memory impact from IE's "private" working set appears relatively small). "resident" refers to virtual memory space that is currently in physical RAM, as opposed to being paged out on a disk.

The fact that your "resident" memory is smaller than your "private" memory suggests that maybe some of Firefox's own data caches are paged out to disk. All browsers maintain a cache hierarchy both in-memory and on-disk, but it gets a bit silly if users have their in-memory caches so full that they get swapped out to disk anyhow. Opera browser has an "automatic" setting for the in-memory cache which should eliminate this, but I don't know about FF.

Re:OM NOM NOM!

[smellotron]

libc requests and releases pools of memory from the OS rather than making OS level requests every time it needs memory, and unless a pool is completely unused, it can't be released.

FTFY; this behavior is not specific to FF. Custom memory pools reduce the pressure on the generic/heterogeneous allocator (malloc) but they do not fundamentally change how the program gets memory from the operating system (sbrk). I don't know the syscalls on the Win32 side, but it's analogous.

Re:OM NOM NOM!

[starofale]

Two can play at this game. My Firefox 9.0.1 with 24 tabs running for a few hours is using 509MB resident memory.

Looks like Opera is quite the memory hog.



How about we don't use anecdotal evidence to judge browsers we don't use?

Re:OM NOM NOM!

[UpnAtom]

Opera will run that in about 50MB if need be. It's designed to use spare RAM for caching which is marked for instant release if other programs request it.

I believe Firefox copied this feature too, which makes most of this discussion redundant.

Also, 11.61 is out. :)

Re:OM NOM NOM!

[IkeTo]

malloc uses mmap for large memory blocks, not sbrk.

Re:OM NOM NOM!

[b4dc0d3r]

NoScript and Firebug are not memory eating extensions. Firebug doesn't do anything unless it's enabled, and NoScript tends to reduce memory because scripts don't load unnecessary objects. The whitelist, even if very large, typically consumes less memory than what it blocks. Especially if it is preventing Flash from even being loaded (no plugin-container overhead).

I don't use AdBlock Plus, but I would suggest it probably uses a lot more memory than one might think, based on what I know of its workings.

Re:OM NOM NOM!

[smellotron]

mmap for large memory blocks

Yep, forgot about that. Thank you. The principle applies equally for conditions where pools are encouraged (small, fixed-sized, frequently allocated/deallocated objects).

Does this mean...

[Anonymous Coward]

... it'll just leak memory more slowly?

*More* outsourcing?! Bloody "globalization"!

[zooblethorpe]

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

Caring

[SuperKendall]

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:Caring

[Tenebrousedge]

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:Caring

[jedwidz]

I've heard that recommendation a lot but I fail to comprehend the logic behind it.

If you don't want/need swap, you can optimize for performance by disabling it.

If you do want/need swap, you can optimize for performance by using a fast drive, e.g. an SSD.

Re:Caring

[CapOblivious2010]

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.

So? I'd rather have my swap "disk" (SSD) fail than have my OS or data disks fail. If the swap disk fails, the system crashes, you replace the disk, and it boots right up. BFD!

...and yes, the idea of swapping from one kind of ram to another kind of ram is sort of silly - but try to get a few hundred gigs of DDR3 for a couple hundred bucks. When you're running multiple VMs, 8GB or even 16GB gets used up real fast.

Re:Caring

[Anonymous Coward]

If you have an SSD, disable swap. There's no reason to be continually writing to one section of the disk.

Your SSD won't be continually writing one section of the disk. It has low level wear-leveling stuff. It still might not be the best idea. But, it may be faster to use an SSD than a spinning disk for this.

Re:Caring

[the_one(2)]

A normal SSD spreads writes out with wear leveling so there is no reason to worry about writing singular blocks too much.

Re:Caring

[Anonymous Coward]

You're still increasing the number of writes to the device by an order of magnitude or so. It will wear out correspondingly faster. Wear leveling may extend the lifespan of the device but it also will result in the blocks all failing at almost the same time, so when it does fail it's unlikely that you can get much data off it, unlike floppies or fixed disks.

Re:Caring

[badkarmadayaccount]

better idea, leave default swappiness, even slightly increase it, use appropriate block IO scheduler for load leveling. Done. Now you effectively have more ram than you'll ever need on the given machine configuration.

Plugins/Extensions

[JSBiff]

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:Plugins/Extensions

[bursch-X]

WebGL. I see Google Maps and their newer 3D approaches to totally become one of the places where people will be happy in the future to have a 64-bit capable browser if they want to load a complete 3D high-resolution map of, say, Rome.

The boy who cried "Leak!"

[jlebar]

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:The boy who cried "Leak!"

[Anonymous Coward]

Don't worry, there will always be arrogant people telling you that it's their right to wag their fingers at you for giving you a free product, because it has a few flaws. And because you actually do have a process for listening to their complaints, they presume you have infinite time and resources to deal with problems.. all they have to do is treat you like a dog that's peed on the rug, and you'll fall into line.

The rest of us are happy. Those of us who participate in your bug-reporting process and pay attention to your efforts appreciate them. Don't let the whiners ruin your day. Just let them pretend they're fighting some sort of crusade against complacency. Especially those people who understand that seeing memory leak doesn't mean it's the same bug that's been leaking for the past 10 years.

Re:The boy who cried "Leak!"

[Anonymous Coward]

I think you're twisting the fable to suit your own biases.

From my perspective it went more like the Monty Python skit about the parrot.

Customer: There's a wolf!

Clerk: What wolf? There aren't any wolves around here!

Customer: That one, right there!

Clerk: Oh, that's not a wolf. It's a coyote. Perfectly normal for coyotes to hang around. Just ignore it.

Customer: No, no, it's definitely a wolf. And why should I ignore it?

Clerk: I think you're just misunderstanding things.

Customer: Well what about that other one over there?

Clerk: I don't see a wolf.

Customer: The great big grey thing with fangs!

Clerk: Ohhhh. That's a bear. We keep them around to scare the wolves off.

Customer: I think I'd bloody well know a bear if I saw one. It's a wolf.

Clerk: Definitely a bear. And even if it was a wolf, the bear would scare it off.

Customer: It's not a bear! And why would you have bears to scare wolves off if you said there aren't any wolves?

Clerk: Well, there's wolves in other places, and we don't want any to show up over here.

Customer: Look, a wolf's been eating all the groceries in my house, and scared poor little Mary. I saw it, even got pictures of it.

Clerk: Oh, well that's what bears do. We want them to do that. Helps keep things clean. Sorry about Mary, but maybe you should get a bigger house so the bear has more room to move around without running into her.

Customer: //incredulous// What?

Clerk: The bears. Keep things clean, but gotta feed 'em. No problem then, right? Cheerio.

Customer: What about the wolf??

. //Hunter enters carrying a dead wolf.//

Hunter: Oi. Found that wolf that was rummaging around lately. Managed to track it down and kill it.

Clerk: There, see? Wolf problem solved.

Customer: You said there wasn't any wolf!

Clerk: Well obviously the bear scared it out so we could find it.

Customer: That's the wolf I was trying to tell you about!

Clerk: Well, you should have said so, then.

. //Screams of rage//

Simple issue: trust. Over the course of several years you made it less and less likely that people would trust what you say, and now you want people to completely ignore that and trust everything you say without any reservation. Sorry if you're tired of it, but you're going to have to earn that trust back.

Also, your little analogy about The Boy Who Cried Wolf makes it seem as if the issue of trust was on the user's end, rather than yours. You've got that backwards.

Re:The boy who cried "Leak!"

[squiggleslash]

While I can't agree that the memory problems are solved, having read your presentation I have to thank you for the good work you're doing to make Firefox usable again.

People are not being malicious when they say they're still noticing the problems. I don't know if the average Mozilla developer simply loads up a bunch of text only pages and says "Wow, it's fast now" or what exactly, but there's a gulf between what some are saying about Firefox being fixed, and the experience of the rest of us. Nobody's trying to "punish" Firefox by pointing it out, it's just we want a stable, smooth, browser, and we want it to be Firefox, and we're getting upset because Firefox used to be that, and isn't today.

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.

So... look, if we didn't love Firefox, we wouldn't be upset. I feel dirty, and without the tools I want to use, when I use Chrome, but the reality is that I keep a Chrome window open at all times and use that for much of my regular browsing.

So... thank you for the work you're doing. Don't let the fact people are still criticizing Firefox's memory issues mean that your work isn't appreciated. I appreciate you hunting the wolves, just understand it doesn't matter that the town crier is saying they're gone, I was attacked by one just a few hours ago, so they're obviously out there.

Re:The boy who cried "Leak!"

[Lisandro]

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 things in latest versions) and i also appreciate knowing that the team is pursuing active testing of extensions for leaks, which seem to be the main culprit most of the time. If anything, i'm thankful.

Re:The boy who cried "Leak!"

[jo_ham]

I'm not the OP here, but it's more like seeing the users as an antagonist and personally yelling at you rather than at their issues.

For example, the status bar removal situation. We were told in no uncertain terms that it was going away because we didn't need it, and that if you wanted to use it there was an addon.

To put it in Crying Wolf terms:

User: so easy to fend off wolves with this wolf scaring horn.

FF: we're removing the wolf scaring horn, you don't need it. We've put a limited horn function into part of your house totally unrelated to that function.

User: but I used it all the time! Can't you just have an optional wolf scaring horn?

FF: No, there's no space. Some people with smaller houses, vertically, have no room for wolf scaring horns so we're just removing them for everyone. You can install a third party wolf scaring horn though, although the electrical hookup is non standard and it will probably stop working when we repaint your house next month. We're repainting every month now instead of every 6 months by the way.

User: well that's not as good as a native solution, especially if it keeps failing after a house repainting.

FF: We've told the third party makers of things that we've changed our interfaces so that stuff keeps working between repaints, so it's not our fault.

User: well, that doesn't help me if you force me to rely on a third party wolf scaring horn and the guy who makes it doesn't follow your new method for third party horn modifications.

FF: well, tough luck, it's not coming back. You told us to reduce bloat! Here, just use the AwesomeBar! It will distract you.

*****

I understand the massive issues with a project the size and complexity with FF, but it reached a point where we were just going in different directions - I'd been using a gecko-based browser since before it was called FF, running Mozilla from a zip disk alongside Pegasus mail on Win 98, then onto W2k and later OS X, but eventually I realised that I was internally bitching about solving problems with my browser more than I was using it, and I moved to another one.

That's not to say they don't also have problems - Safari has a status bar, but it has memory leaks like you wouldn't believe with AdBlock installed, and Chrome occasionally freaks out with layout, despite using WebKit and the same site in Safari being just fine.

I bear no personal ill-will to the FF developers after many years of use, but it's simply not doing what I want it to do (minimal addons to get the function I want, without updating too frequently).

Re:The boy who cried "Leak!"

[jlebar]

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:The boy who cried "Leak!"

[jlebar]

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/

Re:The boy who cried "Leak!"

[jo_ham]

Oh I agree - like I say, I appreciate the difficulties of such a large project.

The status bar addon isn't something I want to install, so I did move on - to another browser. No hard feelings.

Re:The boy who cried "Leak!"

[webnut77]

First, let me thank you, jlebar, and the other Firefox developers for all the work you do on FF. I use it with FireBug to develop web pages and they are invaluable tools that help me do my work.

It is because we love FF that we are complaining. If I didn't care about FF, I wouldn't even bother complaining. I would just move on.

I never understood the reason for removing the status line. I've heard the reasoning that it saves vertical space for the laptop/tablet/smartphone users. However, this reasoning really doesn't hold water since all along a user could easily disable it. I, for one, constantly use the status bar and am alarmed by the decision to remove it. Someone has decided for me that I don't need it.

I've seen posts here on Slashdot from one user that thinks the desktop is now a dinosaur and will eventually die off. This is a ludicrous idea that I fear the the FF developers are buying into. I have 19 FF windows open spread over two 24 inch monitors which allows me to view documentation as well as the web page I am currently developing. I also have 7 Xshell widows open to monitor a few servers. Can't see all this happening on a tablet let alone a smartphone.

To wrap this up, I hope this provides some insight to the frustration that I, and others, are experiencing.

PS. I wouldn't even begin to know what to put in a bug report about the memory problems. Seems like someone in the FF organization should be able to leave FF open two or three days and use it extensively to re-create the problem. Watch a few Netflix movies, configure Zabbix, and leave the @#$% Slashdot main page open that refreshes itself despite my profile indicating not to. FF will slow to an unbearable crawl. Windows XP Pro 64-bit with 8 GB RAM.

Re:The boy who cried "Leak!"

[Rary]

I've just been scanning this thread, and I just want to chime in with one comment for you. Firefox rocks. I have used it for years, and have no plan to change that. I have not experienced the problems that others around here are complaining about. For me, it just works, at least as well as any other browser I've tried, and certainly better than certain ones.

I'm sure you hear enough complaints that I thought maybe you'd want to hear from one of the great many of us who are just silently using and enjoying what you've worked so hard on.

Re:The boy who cried "Leak!"

[steelfood]

Yeah, but extensions are the cause of memory leaks.

You can't have it both ways. You can't point to extensions as a way to make up for deliberately discarded functionality, and then point to extensions as a source of your user's problems. One or the other needs to be remedied*. Otherwise, your user is going to be fed up and go away to a suitable alternative when one presents itself.

* Given that you have control over one of these, while you have little control over the other, I'd say there's only one real choice--assuming you want to stop hemorrhaging users that is.

Re:The boy who cried "Leak!"

[idbeholda]

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

Re:The boy who cried "Leak!"

[Anonymous Coward]

I never understood the reason for removing the status line. I've heard the reasoning that it saves vertical space for the laptop/tablet/smartphone users. However, this reasoning really doesn't hold water since all along a user could easily disable it. I, for one, constantly use the status bar and am alarmed by the decision to remove it. Someone has decided for me that I don't need it.

Use it for what?

My memory is bad, I'm using Firefox Release, Chrome and IE9, none of which have status bars. I can honestly tell you that I can't even remember what the bar did in the first place that was supposedly useful. There's checking where links go before you click but the popup tooltip thing does that when you need it.

The only thing I can think of is the old "loading object 19 of 296" message and the meaningless progress bar that filled based on time rather than data.

Re:The boy who cried "Leak!"

[Anonymous Coward]

Try this:

He saw a wolf. He was told that wolves are extinct. A wolf ate his food. He was again told that wolves are extinct. A wolf ate his kid. Again he was told that wolves are extinct.

Now, the people who have claimed for years that wolves are extinct, tell they have killed three wolves. For some reason, he doesn't feel safe yet, and keeps his shogun around.

Re:The boy who cried "Leak!"

[Joce640k]

"I left Firefox open for a couple of days and it used lots of memory" isn't a 'description', it's a nightmare for a developer and will mostly get ignored.

I think he means something more like:

* Open page you suspect causes problems
* Wait for mush to happen
* Open new tab
* Type "about:memory" in the URL bar
* Send that to him

Re:The boy who cried "Leak!"

[squiggleslash]

Thank you. I need to figure out how to make a useful bug report, but I will do that.

Re:The boy who cried "Leak!"

[jlebar]

"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 problem occurs. Moreover, if the problem has to do with Yahoo Mail specifically, it may have to do with the reporter's specific YM configuration. Enough Firefox users use Yahoo Mail that if anyone who opened it experienced cringe-worthy performance, we might have heard about it.

The quote above is a fine initial post in a bug report. But we'd need to go back and forth for a bit to establish set of steps to reproduce that might lead a developer somewhere.

Re:The boy who cried "Leak!"

[jlebar]

Yeah, but extensions are the cause of memory leaks.

Not all extensions cause leaks. At this point, perhaps most do. We found leaks in four of the top five add-ons, although most of those are now fixed.

But I'd be kind of surprised if that Status-Bar-4-Evar add-on leaks. Leakiness is usually caused by touching page content, which that add-on (hopefully!) doesn't do. Try it and see!

You can't have it both ways.

I do agree in general that we can't tout extensions as Firefox's killer feature and allow them to destroy users' experience. 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:The boy who cried "Leak!"

[jlebar]

I never understood the reason for removing the status line. I've heard the reasoning that it saves vertical space for the laptop/tablet/smartphone users. However, this reasoning really doesn't hold water since all along a user could easily disable it. I, for one, constantly use the status bar and am alarmed by the decision to remove it. Someone has decided for me that I don't need it.

Since I've been paying attention, it's always been Mozilla's UI philosophy to do what we think is best for users and not to clutter the UI with an option for every feature someone might want to change. In other words, we've always decided for you, for better or for worse. It just might not have seemed that way, when you liked the decisions we made.

But we also make a browser which is flexible enough to let you install an extension which reverts you back to the old functionality. For those 1% of people who don't like it, there's an out. I guess I still don't understand why this is such a big deal to people. Go get the extension and be happy again.

PS. I wouldn't even begin to know what to put in a bug report about the memory problems.

Don't be afraid of filing a bad bug. A lot of these "snapiness" issues we've been debugging lately start out with really tough steps to reproduce: "Browse like I do for a few days." We have means of figuring out what's going on, even in those cases. But we can't do anything unless you take the first step and open a bug on bugzilla.

Re:The boy who cried "Leak!"

[jlebar]

I'm sure you hear enough complaints that I thought maybe you'd want to hear from one of the great many of us who are just silently using and enjoying what you've worked so hard on.

We all appreciate this, I think. Thanks!

Re:The boy who cried "Leak!"

[jlebar]

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.

Thank you. I need to figure out how to make a useful bug report, but I will do that.

The first quote is plenty to file with. We'll ask some questions, but we'd do that no matter what you filed with. :)

If you want to get more info, that's great. But don't let fear of filing an imperfect report keep you from filing anything at all!

Re:The boy who cried "Leak!"

[Dagger2]

The hint is in its new name: "Add-on bar". I have icons for Stylesheet Chooser Plus, Textarea Cache, Adblock Plus, Greasemonkey, Screengrab, Stylish, Tabhunter, Yesscript, CipherFox, and Ghostery in there.

Now, yes, I could get rid of some of these. But others I actually use, and if I hid the status bar, where would I put them? So I don't.

The dumb bit comes in when the status bar isn't hidden: the mouseover link display continues to show in that tooltip, which is rendered above the big blank gap in the status bar where it used to be shown. This makes no sense to me. It takes up more space and it's irritating; why would I possibly want it? Yet someone at Mozilla has decided that it's being moved there and I'm going to like it.

I feel this is part of the reason we're losing so many users to Chrome; between the statusbar, tabs-on-top and in the titlebar, no menu bar, the removal of all color from the toolbars, putting the update checker in the About dialog, showing non-canonicalized URLs, and in-content UI, most of the things that annoy me about Chrome have come to Firefox. Since I'm going to dislike the UI anyway, why wouldn't I just move to Chrome, where I can dislike it faster?

And no: for those of us left, we can't just shut up and move on either. The UI is still sucking, and being quiet about it just paves the way for more suckage (see for instance the tabs-on-top in Thunderbird, which has no option to turn it off -- expect that to arrive in Firefox the next time they do a major change to the theme.)

Re:The boy who cried "Leak!"

[Dagger2]

In 3.6, I have three extensions installed to revert to old behaviour. In Nightly, I have fifteen, plus a ton of CSS in Stylish that I've written just to get the UI to match with the "Windows Classic" style I use in Windows.

Installing that many extensions is a chore. Worse, it wasn't just a matter of installing them and being happy: I had to write over half of them myself. I have to keep hunting down or writing new ones as stuff keeps changing in the browser (like the hiding of the forward button, the removing of the address bar favicon, the home tab...)

This is why it's a big deal to me.

Re:The boy who cried "Leak!"

[jlebar]

In 3.6, I have three extensions installed to revert to old behaviour. In Nightly, I have fifteen, plus a ton of CSS in Stylish that I've written just to get the UI to match with the "Windows Classic" style I use in Windows.

That sounds unpleasant!

But you'll admit that you're an edge case, right? Even most of the trolls here on /. complain about one or two things (awesomebar, status bar), but not fifteen different behaviors they hate.

So now the question is: How much energy should Mozilla devote towards specifically your needs? Your needs are no less valid than anyone else's, but the converse is true too: Everyone else's needs are no less valid than yours. So when faced with the choice between making Firefox more usable for 399 million people, or adding and maintaining fifteen UI options so you can make Firefox work the way you and your million closest friends want, what do you think we should do?

There is a real cost even to adding and maintaining a "disable X" button to the UI, and if we did that every time we changed something, as you seem to be asking, we'd quickly end up doing nothing but fix bugs in the exponentially-growing set of ways one can configure Firefox's UI.

Or maybe you think we simply shouldn't change anything, ever? That might satisfy you, but again, we agree that you're an edge case, right? Do you honestly think that would satisfy everyone?

Re:The boy who cried "Leak!"

[squiggleslash]

Just to let you know, I haven't forgotten. But I am trying to make the report useful.

What I'm doing is using the version ten release from http://ppa.launchpad.net/mozillateam/firefox-next/ubuntu/. The last version I downloaded, on Wednesday, has crashed when I left it (twice) alone for a couple of days with Twitter and Yahoo Mail tabs. I've reported those crashes via the bug reporter pop-up that comes up. I'm downloading the latest build now.

What I will say is that while the version of ten I had prior to Wednesday exhibited the "mush" issues I'm talking about, the one that's crashed twice hasn't. Which is why I'm holding off. It could be it's growing much more slowly and then crashing, or alternatively it could be crashing for some entirely unrelated issue and the mush issues I've been experiencing are fixed. I'll let you know either way, and file a bug report if the mush thing comes back.

Re:The boy who cried "Leak!"

[jlebar]

If you continue seeing crashes, it would be helpful if you'd also test with the binaries Mozilla releases. I think the Ubuntu team usually does a good job packaging Firefox, but there are a lot of variables here...

FYI, if you go to about:crashes, you can see all your recent crash reports. These often have links to the relevant bugs.

leak semantics

[epine]

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-core, once they fessed up. And I'm looking forward to more of the same with the add-ons, too. No grudges here, so long as the truth is served.

FWIW, I participated heavily during the original FF 3 beta cycle. With fewer plug-ins than now, my browser was leaking at the rate of 300MB/day. Under a heavily laden 3.6.3 that's down to about 50MB/day. Livable, but I'm not dancing a jig in the streets.

But now I've got Unity to complain about, so this seems like small fish.

You mispelled UNIX

[Anonymous Coward]

Maybe we should go back to UNIX design with single threaded non-premptive kernels with horrible scaling properties.

Re:You mispelled UNIX

[Alex Belits]

Maybe we should go back to UNIX design with single threaded

Unix always had processes with efficient FIFO-style communications and IO-controlled scheduling implemented between them. The idea of using shared memory (what would be an equivalent of multithreading) in such environment was seen as a very special case for exchanging bulk data or handling shared read-only resources.

The idea of this design was exactly the same as what was described in the article -- reduce the amount of things to track, keep private data to whatever limited scope it belongs. Plus, of course, security because Unix processes also provide security boundaries.

Threads were always seen as a horrible, unsafe hack, justified more often by Windows upbringing of the developer than by any legitimate advantages.

non-premptive kernels

Are you ignorant or stupid?

with horrible scaling properties

Over the whole history, Unix-based and Unix-like systems were, and remain superior in performance and scalability over Windows.

Re:You mispelled UNIX

[Anonymous Coward]

The idea of using shared memory (what would be an equivalent of multithreading) in such environment was seen as a very special case for exchanging bulk data or handling shared read-only resources.

Process switching causes TLB and other context flushes. This breaks almost all CPU speculative execution. Synchronizing shared memory between processes is expensive. But the fact is traditional UNIX design does not exist anymore. Linux and other modern UNIX based OSs have already worked around the horrible UNIX design via hacks and patches. Linux famously has struggled and continues to struggle on SMP/Multi-core systems.

Threads were always seen as a horrible, unsafe hack, justified more often by Windows upbringing of the developer than by any legitimate advantages.

lol

Are you ignorant or stupid?

Neither. Thanks.

Over the whole history, Unix-based and Unix-like systems were, and remain superior in performance and scalability over Windows.

How cute. This one thinks Windows and UNIX are the only two operating systems. While there are much better designs than NT.. NT design is superior to Linux in every single aspect. Linux is like the low-quality made-in-china shit that everybody uses because its free/cheap.

Re:You mispelled UNIX

[Alex Belits]

Process switching causes TLB and other context flushes. This breaks almost all CPU speculative execution.

That depends on the hardware and OS, and may be applicable to context switching for processes, threads or even simple interrupts handling. OS and hardware design is supposed to achieve as little invalidation as possible, however you, knowing nothing but Windows, believe that context switch between processes is a horribly heavyweight operation everywhere.

Synchronizing shared memory between processes is expensive.

Shared memory is not synchronized, you dolt -- it's physically shared. Cache is synchronized, by hardware. Access to writable shared memory is expensive to synchronize, what is my whole point -- it is avoided through use of interprocess communication.

But the fact is traditional UNIX design does not exist anymore. Linux and other modern UNIX based OSs have already worked around the horrible UNIX design via hacks and patches. Linux famously has struggled and continues to struggle on SMP/Multi-core systems.

You know absolutely nothing about Unix and Linux design. All modern operating systems went from single-CPU to multi-CPU design by establishing a clumsy common kernel lock, then splitting it and switching to other synchronization mechanisms wherever possible. This had absolutely nothing to do with OS design, and was more relevant to things like interrupt handling, where hardware design forces resources to be shared regardless of the software developers' intentions. Some monstrosities already had billions of tiny little locks in place because their design sucked ass on any number of CPUs, however that did not help them to achieve anything useful.

How cute. This one thinks Windows and UNIX are the only two operating systems.

No, there were two kinds of operating systems -- "Unix-like" and "horrible shit". Windows is firmly in the second category. So is VMS, but for other reasons.

While there are much better designs than NT.. NT design is superior to Linux in every single aspect.

For all practical purposes, there is no such thing as "NT design". NT kernel was developed in hope to create and follow some sane design, however all advantages were immediately and completely negated by placing a horrible piece of shit Win32 as the only interface available to applications. If there are any remnants of sanity in NT/2000/XP/... line of Windows, they are buried under piles of crap.

Linux is like the low-quality made-in-china shit that everybody uses because its free/cheap.

I see, Microsoft started another "Get the Facts" campaign. Die in a fire.

Re:You mispelled UNIX

[Anonymous Coward]

I think you got that troll problem from insulting the fine Mozilla on Windows people. Threads were meant originally for concurrency and not parallelism. Maybe one day CSP + data parallelism rises again with all the heterogeneity going on.

Re:You mispelled UNIX

[Anonymous Coward]

Shared memory is not synchronized, you dolt -- it's physically shared. Cache is synchronized, by hardware. Access to writable shared memory is expensive to synchronize, what is my whole point -- it is avoided through use of interprocess communication

Its obvious what I meant by synchronization. You have to protect concurrent write-access across processes. Threads can have finer control over this and you can in many cases avoid taking a lock when you can guarantee atomicity.

lol IPC. lol. Seriously? have you written a single high performance application in your life? Any IPC overhead will reduce performance compared to shared memory via threads.Also IPC has to implemented through kernel threads causing even more horrible usermode to kernel mode switching.

This had absolutely nothing to do with OS design, and was more relevant to things like interrupt handling, where hardware design forces resources to be shared regardless of the software developers' intentions.

Traditional single processor UNIX design was shitty as hell. All system calls were were blocking in kernel mode for the period of the time slice. Only way around this was to manually release control via wait() (in kernel mode). Linux was the same till 2.4.

I see, Microsoft started another "Get the Facts" campaign. Die in a fire.

Nah. I don't work for them. But I am forced to ship a mulit-platform library at work and have to deal with shitty unix design daily. All people like you should be laughed at and ridiculed. Its obvious you have never looked at the shortcomings this shit called UNIX. You are nothing but a cheerleader with an empty head.

Re:You mispelled UNIX

[Alex Belits]

Its obvious what I meant by synchronization. You have to protect concurrent write-access across processes.

Actually, when shared memory is used for interprocess communications, you just should avoid concurrent write access (or write concurrent with read) like the plague. Then, if you can't avoid it, you should check if you are not, by any chance, an idiot, and if so, leave software development forever. Only then, if you have a reliable confirmation that it's unavoidable and you are not an idiot, you should think of a locking scheme.

lol IPC. lol. Seriously? have you written a single high performance application in your life? Any IPC overhead will reduce performance compared to shared memory via threads.Also IPC has to implemented through kernel threads causing even more horrible usermode to kernel mode switching.

Actually yes, I did. Unix pipes and sockets are considered to be "I/O" and affect scheduler, so it can optimize the timing and order of waking up the processes involved. Shared memory is considered memory access, and does not affect anything at all unless it's unlucky enough to cause a page-in, so actual scheduling happens in locking/semaphores. In its turn, multitude of semaphores (managed explicitly by applications but all affecting the scheduler) causes suboptimal scheduling compared to scheduler-managed waiting/sleep by applications (one state per file descriptor).

On multicore/multi-CPU systems the superiority of the Unix model is even more noticeable because processes can avoid sleeping even when they are closely related -- kernel just passes data asynchronously. Shared memory can be used for bulk data handling, to reduce copying while all handling of data-passing operations happen asynchronously.

This is not the case on Windows because Windows IPC is written by idiots.

Traditional single processor UNIX design was shitty as hell. All system calls were were blocking in kernel mode for the period of the time slice. Only way around this was to manually release control via wait() (in kernel mode). Linux was the same till 2.4.

Except, of course:
1. From the process' point of view all system calls cause the process to sleep regardless of the model used. The question is only for how long.
2. It's a matter of quality of implementation for kernel, for how long it may have to run without causing scheduler to be invoked. On SMP, it's even less of a problem as long as there is no global lock (what you are probably pretending to be describing).
3. On system with preemptive kernel, latency is reduced, while performance mostly stays the same or decreases due to more context switches while performing the same work. Please note that in Unix, a process will be woken up sooner if another process is trying to communicate with it, so "pipeline" processing stays optimal regardless of the scheduler invokation model. Process sleep time is not a matter of performance or scalability but latency, and it was long ago solved in all Unix-like systems without affecting their overall design.
4. wait() is a system call, so I seriously doubt that any Unix used such function name for an equivalent of sched_yield().

Nah. I don't work for them. But I am forced to ship a mulit-platform library at work and have to deal with shitty unix design daily. All people like you should be laughed at and ridiculed.

I have seen plenty of "multi-platform" development that was actually Windows development with thin wrapping that shoehorns it into all other systems. For those projects, indeed, nothing but Windows works because they follow a broken Windows-oriented application design. We need less of those projects and less of developers with Windows-bent minds.

Its obvious you have never looked at the shortcomings this shit called UNIX. You are nothing but a cheerleader with an empty head.

Over whole 90's I couldn't read half a kilobyte of any computer-related text without seeing anti-Unix propaganda stuffed in it by people like you. It was full of shit then, and it is full of shit now.

Never need to restart firefox

[Chirs]

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:Never need to restart firefox

[Anonymous Coward]

Then you've obviously never updated it as the update will auto-restart it. Shame on you.

Huzzah!

[Anonymous Coward]

Does this mean Firefox will stop freezing up every couple seconds while I'm trying to do complicated tasks like scrolling down a page?

If your weren't up to the task...

[Anonymous Coward]

...you should have just said so.

Jahovascript...

[DigiTechGuy]

Baptise your browser!

Re:Jahovascript...

[Anonymous Coward]

Be careful, you could get stoned for saying that.....

Sorry, need swap

[SuperKendall]

I do a lot of photo editing, sometimes swap is simply required.

I also so no need to make my laptop noisy and power draining again with the inclusion of a spinning disk.

Yes it wears out the SSD quicker; who cares? I'm pretty sure I'll be replacing the SSD (or laptop) long before that ever might become an issue.

Terminal Servers

[Anonymous Coward]

80 users, 32GB, and suddenly a browser that gorges itself on RAM to fake performance optimization isn't as attractive any more. I'm looking at you, Chrom(ium).

BTW, Firefox running on my TS farm of 10 machines for 3+ years, *zero* memory related issues, and crashes are in the low 1-2% of session range after 4+ hours of uptime per session. I don't know what the fuck people are doing with their browsers to make them crash all the time. Also, flashblock is a godsend on terminal servers.

Re:angry

[bursch-X]

Well probably something like this http://www.youtube.com/watch?gl=US&v=_dErAZL1Hr8

Wait! I need it those...

[Anonymous Coward]

I think this affects me, as I understand it, no separate thread for web-workers.
It was my intention to use this in my Javascript Vic-20 emulators to run low ipc (1 kb/s) peripheral devices like disk drives.
As on core 2 duos it consumes most of one thread on Firefox to just do the computer emulation.

http://www.mdawson.net/vic20chrome/vic20.php

Re:Wait! I need it those...

[matsondawson]

Ah, ignore this. Others have said web-workers get their own single-threaded runtime.

get more ram its cheap

[cheekyboy]

I wouldnt settle for anything below 4 gig, and I prefer 8gig for general use. Server side, 16gig is so cheap, id make it default

Re:get more ram its cheap

[CCurzon]

For my work machine, 2 GB is more than sufficient as almost everything I do is online. When Firefox was really acting up I just switched to IE (because of a compatibility issue with Chrome and a site I needed) and the memory problems went away. If it wasn't for the plugins and the way Firefox handled the tabs I was using I would have stayed with IE.

Firefox 9 unusably slow on system with 128M of RAM

[bzipitidoo]

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.

you answered it

[cheekyboy]

There you go, no flash, I bet other problems are caused by flash, i know often flash can leak too but appear as firefox.

We need to kill flash.

Re:Firefox 9 unusably slow on system with 128M of

[Anonymous Coward]

Pentium II is from 1998. You should use a browser from a comparable age. FF 3 is about at the limit of what you can expect to run on that hardware reasonably well. Anything more recent has been developed with more CPU and RAM in mind but you might check LuaKIT. Definitely not intuitive but slim.

Re:Firefox 9 unusably slow on system with 128M of

[Anonymous Coward]

If you had looked at system requirement, you would have seen FF9 recommends 512 MB of RAM. Earlier versions necessitate less, linked to the most common configuration (read: amout of avaible RAM) at the time.

Re:Firefox 9 unusably slow on system with 128M of

[Lennie]

btrffs sucks for frequent filesyetem sync calls, even the author of btrfs says that.

Firefox is known to do many filesystem sync calls.

So I'm not surprised the combination sucked.

You should try ext4, you could even choose to use ext4 without journaling.

One Giant Step Backward for Browsers

[Anonymous Coward]

I can see the why this is a problem, I have seen memory usage upwards of 1 Gig in real memory, so yes it seems like a good choice but is this not severely restricting the future of this browser? I mean Memory management is a problem, stopping processes, (threads that have already begun is the issue and that is client side)

Multi-threading, is the future think of it like a multi dimensional array, where you can productively access several products at one time, with the web becoming more and more of a SAAS based property this move is severely restrictive of what could be a great thing.

I am glad I heard this story because I was developing a product exclusively for use with Firefox now I am going to have to move it over to Google Chrome.

The simple fact is that the desktop is slowly moving over to SAAS and with a single thread, the result will be a slow unresponsive browser that sucks

Re:Firefox 9 unusably slow on system with 128M of

[UpnAtom]

I'd be interested to know how the latest Opera runs.

Let's not...

[Anonymous Coward]

To infinity, and beyond!

Re:Do you know how bug reports work?

[b4dc0d3r]

You insist these are only "one guy". You should have left that out if you wanted to prove your point. I'm not sure if you're familiar with filing bugs, but if one guy reports something, and another guy reports the same thing, one of those will be closed as a duplicate. If one guy is having that issue, it most likely means more than one guy is seeing it, and either not noticing, not reporting, or watching that bug report because either he found it was already reported or his was closed as a dupe.

Also, the fact that there is no reply doesn't mean it's not an issue. Effectively no insight can be had, it does not prove there are or are not memory leaks.

Given the history of FireFox, where devs insisted for *years* that there were no problems, and then suddenly a pile of memory allocation problems got fixed, I give no more credence to a developer saying it's "probably" not an issue than a user reporting it as an issue. It's a dead split in terms of reputation, and as long as it remains open I give the reporter the benefit of the doubt. I think that's fair.

It sounds like you believe FireFox is rock-solid, and are looking for any evidence to bolster your case, rather than being dispassionate and accepting and evaluating evidence on its own merits. Maybe if you try again, you might be able to re-phrase this in a way that might away someone who does not already agree with you.

Re:Firefox 9 unusably slow on system with 128M of

[bzipitidoo]

Thanks! That could explain why I saw btrfs processes using so much CPU time. btrfs-endio sometimes used more than Firefox itself.

Thing I don't like about the ext's is they're not very space efficient, and that can make a difference on tiny hard drives such as the 8G this system has. Reiserfs is pretty good with space, and reiser4 was even better. Been wishing for btrfs to mature quickly, as reiser4 is probably dead. I found at least 1 gotcha with xfs. If you don't tune the parameters (block size and such), deletion of a large tree such as the Linux kernel source can take a very long time. Haven't tried any other file systems.

Results from using Firefox 10

[squiggleslash]

No crashes in two days. Firefox is for the most part responsive despite the tests being done (deliberately) in the worst environment I could think of - my work Ubuntu VM. The only time it crawled was using Blogger to write a blog entry, and once I finished, it stopped crawling, which... well, that was itself a massive improvement, if I did something to make it crawl, typically the only way to stop Firefox crawling was to restart it. No longer.

Yahoo Mail and Twitter, together with less memory intensive tabs like GMail, are still sitting there and are usable. I can never figure out what the actual memory figure is, but with a lot of tabs open, it's somewhere between 600M and 1200M (explicit vs vsize); typically I'd expect the figures to be over 1G/over 2G respectively within an hour or two of restarting the browser.

I have to say I'm absolutely delighted. My favorite browser is usable again.

Thank you. Thank you thank you thank you! You've done a wonderful thing.