Slashdot Mirror
Firefox Working to Fix Memory Leaks
Christopher Blanc writes "Many Mozilla community members, including both volunteers and Mozilla Corporation employees, have been
helping to reduce Firefox's memory usage and fix memory leak bugs lately. Hopefully, the result of this effort will be that Firefox 3 uses less memory than Firefox 2 did, especially after it has been used for several hours." Here's hoping. Frequent restarts of things on my computer make me furious. I can't imagine why anyone would tolerate such things.
Too many apps nowadays just throw out RAM like it was yesterdays newspaper! It is sloppy coding, and I'm tired of having to put 2GB of RAM into a system just to surf the net nowadays.
Karma Whoring for Fun and Profit.
I don't mind the memory. I have plenty of gigs even in my laptop. What I mind is the general slowness that I experience with Firefox, and that makes me use Opera on my laptop even though I would feel better using an open source browser.
c++;
everytime I mentioned the memory issue I was always told it was a plugin or there was something wrong with my system or something about my mother and a donkey. Certainly firefox fan boys wouldn't have just attacked me because I questioned something...would they? :-D
Nobody forces you to use Firefox. You can use Opera, Konqueror, links or IE, or any other browser out there...
I tolerate it with an extension that provides a restart button on the toolbar. There are several such extensions. It's also useful for when one wants to quickly restart after installing/enabling/disabling an add-on/theme.
And of course, said extensions reload Firefox with the windows/tabs you had open.
No, and there are no bugs that can't be prevented by writing perfect, correct code.
I think the problem's in the details...
Ok.
Well, it has never been successfully tested.
I can't imagine why anyone would tolerate such things.
Well, my guess is that you *are* tolerating it, as are millions of others, simply because you're using it (either older versions of IE, or current versions of Firefox). Can't comment on IE7 cause I don't use it much, but IE6 rarely crashed for me. IE3-5.5, almost daily crashes.
5 years ago people people would constantly belittle IE users because it had frequent crashes, and pointed to the 'superior' Mozilla suite. Today, FF has morphed in to something which can't be used, with plugins, for more than a couple days max without needing to be reset. I add the caveat in there about 'with plugins' because I'm not sure I know many people who run a bare-metal Firefox. Most people use one or more extensions. This has been a huge marketing push for FF - "It's lean! Only use what you need! Get rid of 'bloat' - package everything in extensions!"
Putting things in extensions makes the base 'leaner' but has lead to a situation where there's no centralized testing for, or even acknowledgement of, memory leak bugs (and other bugs, but this is the obvious one). I still read comments from people who claim they never have leaks with FF (we'll see some on this thread no doubt). It's not that I don't believe them, but their usage patterns are likely different from mine. I have about 6 plugins that I love to use, and I like to keep my browser going. The idea that MSIE is more "stable" than FF for daily usage should remind people that resting on your laurels is not an option. What cut the mustard 5 years ago isn't gonna cut it any more.
creation science book
There are very few "things that require a lot of memory", really. Most of the "things" you do in programming are tradeoffs, often between complexity of implementation, speed and memory requirements. There are usually off the shelf algorithms for each approach. Simplest solutions are often the most inefficient ones.
There is no reason why a minimal web browser could not be implemented, utilizing something like ~100kb of memory, in fact, i have seen the code to one. However, it wont be a) fast b) portable c) full featured d) very easy to understand
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Actually, from what I understood over the last year "THERE IS NO MEMORY PROBLEM".
Every time someone mentions memory issues, the responses are either that it's supposed to consume a gigabyte of ram so that it speeds up the back button or that "there is no memory issue".
Strange, now, that there are suddenly people paying attention to specifically attacking memory use issues that supposedly don't exist.
Well, yeah. And you could prevent any memory leaks at all by requiring that malloc never be used and that everything be placed in static memory.
Kinda hard to code like that, though.
The cake is a pie
I can certainly understand why people are tired of FF memory leaks. Being a FF user myself, with open browser windows and multiple tabs all through the day, I have seen what happens to FF after 4-5 hours of intense browsing. And don't even get me started on the PDF and Flash plugins!
Some would argue that the problem is sloppy coding, or poor encapsulation (a typical OO programmers point of view). But please remember, that even though modern browsers are GUI apps, they are coded much like low-level server processes or protocol stacks. Low-level programming using languages like C and C++ gives you more control and better performance, but at the expense of nicer development features like garbage collection and encapsulation.
Think about it. Would you accept a browser that rendered HTML flawlessly and with absolutely no memory leaks, but took more than a minute to render each page? I think not.
It's an act of balance, and the problem is not _always_ "sloppy coding". It is the increasing complexity of these apps, combined with user demands which push the development towards low-level development languages. From a realistic point of view, any app. written in low-level C with as many lines of codes as FF, is bound to have bugs and leaks. (perhaps except code controlling nuclear reactors and NASA satellites, but then the price of each line of code is also somewhat different).
We - the end users - are not without blame.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
May the Maths Be with you!
Or perhaps they're too busy thinking about clearly-defined objects, robust interfaces, clean documentation and the "big picture" then to worry about moving individual bytes around.
Likewise, I don't trust any artist using Flash today. They should clearly know how to code, in assembly, animation and transitions. Use of a timeline is for losers. The creative process should always be sacrificed for knowing the code inside out.
If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!
Firefox's problem is architectural and not one of garbage collection.
XUL is inherently single-threaded and JavaScript based. Try out any XUL application out there and you'll see how you get the same poor performance, speed and resource usage as with Firefox (try Miro Player and Joost).
The Firefox developers are literally throwing out more C code with every release, replacing it with JavaScript code.
Leaks (in the classical sense) aren't what's causing Firefox's abysmal performance, and this is why Firefox 2 performs worse than Firefox 1.5, despite one of the "features" of Firefox 2 was supposedly plenty of fixed memory leaks.
Actually I'm pretty sure they're in denial as to the cause of their problems. Announcing they're working on fixing "memory leaks" just supports their ability to continue their delusion.
C/C++ and similar languages, on the other hand, force the programmers to manage their resources. In those cases, the programmers would likely be just not designing their programs well, or employing bad resource management. Yes, managing resources can be hard - one project I worked on had to go through several months of testing to get the resources properly managed, and even then some of the resources were still a little uncontrollable due to legacy code or Windows APIs, but overall the thing was pretty stable and any memory leaks were mostly due to Windows APIs.
In either case, I can't tell you how many times I have heard (especially from Java programmers) something along the lines of the following: "RAM is cheap", "processors are getting faster", "computers will be ready for this when we deliver it", "hardware is cheaper than programmers"
No offense, but to rely on hardware always being getting faster, or the cost of adding more RAM always being cheaper, etc. is a bad premise to rely on. Already with multi-core processors we are seeing slower processors being combined into a single processor get the equivalent processing power of a faster processor (e.g. two 1.8 Ghz cores rated equally to a single 3 Ghz core); thus the premise breaks down. Also, I want to be able to do more with the faster processors and additional RAM, rather than simply do the same job I could do yesterday only in "better" software.
The real answer is doing your job right, and using the right tool - which is not necessarily the easiest tool to use either. We also need to get back to writing applications that have good, if not great, performance with minimal resource requirements (e.g. RAM and processor). If we're not going this at the API/library level - at the very least - then the programs and library/APIs that rely on that API/library level will have worse performance no matter what they do. But in either case it doesn't get done unless the programmers do their job, and use tools that allow them to do it.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
A computer, by definition, 'moves bytes around'. One might argue that this is the job of the computer (or language or VM or whatever) and not programmer but if you don't understand how / why and when the bytes are moved around then you are a poorer programmer for it.
C++ yields superior performance and memory usage, than higher level languages, in the hands of a skilled C++ programmer and it can lead to bloatware in the hands of a novice.
There is this old saying about blaming your tools for a poor job and it applies to software development too.
]{
Your argument is nonsense. If what you said held true, large scale applications should be able to be written is assembler. Without high level tools it wouldn't be feasible to create applications the scale we do today.
Wrong. What he is saying is that people who choose to use C/C++ for their applications should be competent enough to properly handle their own allocation and de-allocation of memory. If your abilities as a programmer preclude you from properly managing your application's memory then you need to look at alternatives that will take care of that for you.
There are plenty of languages out there that offer things like garbage collection. Developers need to make better choices about which tools they use to meet their needs, and also understand their limitations and work within those parameters.
dude.
1. Custom malloc/free implementation. (Yes, custom - not from libc.)
2. C++ new/delete operators, which for all I know may be overridden to use their malloc/free.
3. One of the first two with reference counting to decide when to free/delete.
4. JavaScript mark-and-sweep GC.
Dealing with this causes some truly insane hacks, like the absolutely insane DOM C++/JavaScript implementation. (They're C++ objects, exposed as JavaScript objects, using something that's like XPCOM but isn't due to the overhead XPCOM imposes. I really don't understand it.)
Ultimately, though, it's worse than all that. All this crap leaves the code completely opaque, and actively prevents contributors from contributing code without having to learn an insane amount of infrastructure decisions.
It makes a project that's supposed to be open source effectively closed off to only the "official" developers: almost open source in name only.
XUL is inherently single-threaded and JavaScript based. Try out any XUL application out there and you'll see how you get the same poor performance, speed and resource usage as with Firefox (try Miro Player and Joost). ...
Actually I'm pretty sure they're in denial as to the cause of their problems. Announcing they're working on fixing "memory leaks" just supports their ability to continue their delusion.
They're not in denial. They're working on tamarin, a replacement/upgrade of their javascript engine based on the same engine that's in flash 9 / actionscript 3.
Tamarin will run javascript 2, which will to do javascript what the move from actionscript 2 to 3 did for flash/flex. In short: it will make non-toy applications easily done, instead of just marginally feasible. They plan to migrate the firefox UI and extensions to javascript 2, which should negate the performance issues. Only problem: it won't be ready for FF3.
Likewise, I don't trust any artist using Flash today.
That's a good instinct. Never trust anyone using Flash.
Give me Classic Slashdot or give me death!
The biggest memory leak does not show up in firefox itself. It shows up in the X process:
:0 -auth /home/me/.serverauth.30245
TIME+ PID USER CODE VIRT SWAP RES SHR S %CPU %MEM P COMMAND
391:42.00 30262 root 1712 864m 481m 383m 5636 R 20.5 38.0 0 X
19:54.97 5473 me 9.9m 350m 202m 148m 18m S 0.0 14.7 0 firefox/firefox-bin
xrestop shows this:
res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
3600000 295 62 1 2664 119 621592K 12K 621604K ? Firefox Working to Fix Memory Leaks - Mozilla Firefox
In other words, X has over 600MB of memory holding pixmaps for firefox. This grows every time I open a page/tab with images in it.
Closing pages/tabs does not free the memory from X, nor does lowering firefox's various cache settings in the preferences dialog and about:config. Quiting firefox causes X to release the memory. I have to do this at least once a week.
What people call the memory gobbling bug is actually also a CPU hogging bug, and it is still present in Firefox version 2.0.0.7, even though the bug was reported perhaps 5 years ago. Versions 2.0.0.7 and 2.0.0.6 are far more stable than previous versions, but Firefox is still the most unstable program in common use.
The CPU hogging bug in Firefox may be caused by inadequate allocation of resources. Maybe the chaining of the event handler code with numerous windows open is an issue.
Firefox crashes Microsoft Windows. Apparently there is a bug in Windows, or more than one, that causes the entire Microsoft Windows OS to become unstable when Firefox starts CPU hogging. In any case, the only way to get Windows back to a stable state after killing Firefox is to re-start the computer.
It's interesting that Firefox can be used to show that Windows is an unstable OS, in some cases. Linux is completely stable; it is only necessary to kill Firefox to regain resources.
The Firefox CPU hogging bug occurs only during heavy use of Firefox, with many Windows and tabs open for several hours, such as happens when someone in purchasing in a corporate environment is researching computer parts. The problem is made worse if the computer is hibernated or put in standby.
If you open a lot of windows and tabs in Firefox on a laptop, and put the laptop in and out of standby, you will eventually notice that the laptop fan is running all the time, even when there is no activity. That's the CPU bug, and it can potentially shorten the life of your laptop. The fan is often the laptop component that fails first.
It is interesting to note that the latest version of Opera also exhibits CPU hogging, but much less frequently. However, using Opera is not as comfortable because of poor design decisions in Opera.
See: Firefox is the most unstable program in common use.
Firefox developers apparently game the system by abusing those who report bugs: Mozilla Foundation Top 20 Excuses for Not Fixing Firefox Bugs.
Firefox development sometimes resembles playing.
Basically, this seems to be the underlying problem: Winifred Mitchell Baker, the CEO of Mozilla, is a socially uncomfortable lawyer who became CEO when no one thought there was an opportunity. Now Mozilla Foundation is making millions from designating Google as the default search engine.
Winifred has insufficient control over those who work for her, because she doesn't understand what they do. The Firefox CPU hogging and memory gobbling bug would take some serious troubleshooting to find, and no one wants to do the work, apparently.
A well-written C++ program is going to free memory much faster than a GC can. The value of GC is that you don't have to worry about forgetting to free memory, it will happen - eventually.
> Actually, the big language culprits would be those with auto-garbage collection,
> etc. as they tend to have lazier programmers
Actually, it isn't lazier programmers. The problem is that existing garbage collection implementations have horrible memory profile.
If you look at the memory usage of a java program, it's about as bad as a c program that does nothing but leak memory. Practically speaking, java does little to free memory until it has *run out of memory*. Then when it does run out of memory and it needs to clean things up, things get slow as hell.
>The real answer is doing your job right, and using the right tool - which is not necessarily
>the easiest tool to use either.
Yes! Unfortunately, academics and many novice programmers (who just got finished being trained by academics) are unfamiliar with the powerful tools available like C++. Going to school can give you the mistaken impression that garbage collection is *a good thing* because everyone uses it there. The truth is that C++ is a very complicated language with a steep learning curve, but that many times it is simply the only tool that is suitable for the job.
If your program is IO bound, like a web application front end, you are in a great position, because essentially *any* tool will do the job, even if the performance is abysmal. You can use java, ruby, or whatever. And you should, becuase those languages don't present you with the complexity of c++.
Unfortunately, many programs *are not IO bound* and the performance and memory profile of the underlying tool are very important. This is most true of interactive non parializable programs. So, a good example would be bittorrent programs. Consider utorrent vs azureas, one in c++ and one in java. utorrent is fairly light weight and easy to use because of its performance characteristics. Azureus is a powerful and well engineered program, but it sure as hell is slow and chews up memory.
MOD PARENT UP.
See this +5 comment posted below: Firefox's problem is architectural and not one of garbage collection..
Quote: Actually I'm pretty sure they're in denial as to the cause of their problems. Announcing they're working on fixing "memory leaks" just supports their ability to continue their delusion. [my emphasis]
A +4 comment to that comment discusses Firefox's "four separate memory allocation schemes":
"1. Custom malloc/free implementation. (Yes, custom - not from libc.)
2. C++ new/delete operators, which for all I know may be overridden to use their malloc/free.
3. One of the first two with reference counting to decide when to free/delete.
4. JavaScript mark-and-sweep GC.
Dealing with this causes some truly insane hacks..."
Then read the comment they don't want you to see: The memory bug is also a CPU hogging bug. At present, it is marked -1 Flamebait. However, that comment begins to discuss apparent social problems at the Mozilla Foundation, and some of the same material has been marked +5 in the past.