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...
too little too late some people i know have switched to alternatives like Opera or back to IE7 (both use substantially less resources on windows) due to all that ram hogging
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.
The culprit is poor programming.
If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!
Peace sells, but who's buying?
LOL, maybe if you're working in a purely functional programming language :P if that were really the case, you could allocate everything on the stack. In practice, it's often necessary to keep stuff around in dynamically allocated memory between function calls, which is why we have the heap.
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 completely agree. I only have 384MB on the machine from which I'm writing this. There isn't room on the mb for any more than that. I got totally tired of the system seizing up when I used to use Firefox. So I switched to Opera. That's not completely immune to seize-up/memory concumption problems either. So I'll keep an eye open for significant improvements to FF, and just possibly switch back if they fix the memory bugs.
I hope they won't totally forget the folks using older-specification systems, but I have my worries about the FF debugging process: I looked at the blog that was referenced in the article header, and some of the comments sound ominous for quality. The way some of them read, makes it seem as if patches to force memory-release in various situations are just going to be grafted on top of the buggy code. That looks like a recipe for performance loss, compared with the result of fixing the problems at their root?
-wb-
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.
Observing the existence of a memory leak, and knowing where to fix it in your code, are two VERY different things.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
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. Reality check: Most general users do not leave their browsers open for a couple days. Let alone a couple days max. In fact, I wager that most turn their computers off at the end of the day.
No I don't have a source for my statement. But ask people you know who are not in the tech industry. The one outlier group is Mac users, who don't realize that closing a browser window doesn't take the program out of memory.
Help! I'm a slashdot refugee.
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)
The easiest way is to get the flashblock extension and some flash plugin, and never click on a flash thing. There's also some way to make a plugin registered for flash that does nothing.
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.
Actually, I'd say they're not busy enough- if they actually had been, proper memory management should simply fall into place on top of a clean architecture. If you're trying to shoehorn memory management back into something that didn't support it before, you're going to have issues- and this applies whether you're doing c/c++ style management, reference counting, or garbage collecting.
The ringing of the division bell has begun... -PF
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". This technique seems to be working for Microsoft. "THERE ARE NO MORE SECURITY PROBLEMS IN WINDOWS." Hey, maybe that's what the Microsoft developers visiting with the Mozilla developers last year was all about...
My blog
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.
]{
Maybe not, but in the Windows World, Opera is not a viable alternative to many people who find the Opera UI to be excessively daunting for casual use.
The thing that has irritated me about this is that for a very long time, the FireFox leadership has insisted that there where no memory issues, that it was a specific type of use profile, and that if you knew the secrets of how to tweek the configuration file, performance would improve. This is the lamest of excuses.
FireFox is not sold as some kind of "leet" hacker browser, it's sold as a browser for the people. FireFox leadership needs to be more responsive to the feedback from "AVERAGE" users if they want FireFox to be a major player in the browser world. 10% is nice, but it's still only 10%.
If you want news from today, you have to come back tomorrow.
Which brings my second point - even with your original version, this cannot always be done in some languages as some languages remove the ability to free resources. For example, so far as I am aware - and so far as I can tell - Java cannot free memory resources outside of the garbage collector. So much for a programmer being able to manage their resources properly - this is probably also one of the big reasons Java sucks at performance.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
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.
Sorry, but quite a few other browsers (Opera, Konqueror, Safari(the WebKit part anyways)) are written in C++, and they don't seem to have near the problems Firefox has.
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
It is because people accept poor programming as the norm. Oh, yeah, just reboot it and it'll be fine.
I consult for someone who uses ACT! 2005. When they got the upgrade notice, they asked me to check it out. I spoke to ACT! support and they told me "We improved performance by releasing resources that we are no longer using." I said, "THAT IS A BUG FIX!" Anybody writing code outside of school should be doing it, and if I was grading their code, I would take points off for that.
I'd like to see some of these software companies that do this get sued for such poor coding practices.
Fight Spammers!
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.
I use Firefox on Mac (intel) and Windows, with the latest versions on both. I can have Firefox open for a full week on Windows without any problems, however on either Mac I have to restart Firefox about once every day or two, otherwise browsing slows to a crawl. At extremes the whole machine will start to bog down until I "force quit" (kill -9) Firefox. I'll also experience oddness where images will just stop loading.
Running "bare bones" on all Firefox installs, no plugins other than whatever may have been included with the base distribution.
Does anyone else notice this? I've switched back to Safari on the Mac in the meantime.
Statements like this are why I prefer Java programs to C ones. Mandatory bounds checking means that no macho idiot can turn it off, no matter how full of hubris he is. But even assuming a 100% perfect coder, does it really make sense to use his precious time to worry about memory management when the computer can do that automagically ?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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!
My notion is that if you find yourself doing a lot of new/delete statements, it's about time you considered using a programming language that gives you fine-grained and direct control.
Because a routine can still be called that may access the object, so it can't be deallocated? A compiler has to err on the side of caution, but that's an err nonetheless.
A human can know whether an object is truly never going to be called again, whether it's highly unlikely to be called again and so inexpensive to recreate that a special case recreating would be better, or whether it's not used right now, but so expensive to recreate that you want it to stick around anyhow. And other tidbits of information about the program and its IO and data that a compiler or interpreter just doesn't have.
Garbage collection can make a mediocre program more robust, no doubt about it. But it comes at the price of bloat, and will never match the efficiency of a well designed program where the programmer is in full control.
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.
You say that, and you compare it to IE. The only environment where I know people keep a firefox process open for days is on the mac, which doesn't run IE anymore (and btw, safari 2 leaks like a sieve too in my experience). Yes, I have to relaunch ff on my mac every few days. But on windows every time I close my last window, the browser shuts down and all memory is reclaimed. So, on platforms that are not mac, and for "normal" use patterns (i.e. don't leave a browser window with sites open for days), this is a non-issue.
Thiis page may be informative about the issue of memory in firefox: http://plugindoc.mozdev.org/faqs/memusage.html
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.
I agree with both of you. But I'd like to point out that Firefox has garbage collection mechanisms built-in, written in C++. But, as it turns out, garbage collection is not as simple to write as one might think and the presence of garbage collection support makes people lazy, also in C++. And of course, especially in C++ this is a Bad Thing (TM). Lazy programmers quickly start assuming that malloc() and strdup() are auto-collected as well.
Garbage collection in C++ is especially tricky, actually, because a single forgotten pointer "at the broder of the collection scope" can prevent many megabytes of interlinked "garbage collected" data structures from being detected as a loop and hence collected for real. Everybody assumes that the whole thing will auto-die and writes code accordingly, allocating like hell and not caring about resources; nobody is aware of the fact that somewhere in one single file a pointer assignment might be missing that blows their collection dreams out of the water.
Linux user since early January 1992.
I am not sure where you think C++ Programmers are more careful the Other Higher language programmers. A lot of C++ Programmers are really not that good the only reason they use C++ because they had to take it part of their college requirements, thus being the only language they know. Problem with C++ is the fact programming memory is so intensive that most people will be willing to let it leak because of all the extra work it will take to clean it up. They program in C++ not because it is the best tool for the job but the one they know the best. I have seen cases where C++ Project get killed because they take way to long to write and more to debug, while Python, VB or Java Programmers seem to get the job done. Most projects are not Open Source, Most programming is actually just custom program for businesses so these programmers are paid by the hour.
I Agree with you the Duel Cores are not equal to systems with twice the GigaHertz and the singlecore twice as fast system normally will out preform the application written. But that isn't about C++ Program or Java Programming, It is about Multi-Threaded programming. Parallel processing is a different form of programming that most programmers shy away from. But still the fact if you are paying a programmer $20 and hour and it takes them twice as long to get a 10% increase in speed it would be better off buying extra RAM then paying the programmer.
Now if you are getting a boxed application that is different because the cost of application development programming is spread across all the people who buy it. So by Doubling the price of the Shrink Wrapped App. say from $80 to $160 and everyone gets a 10% increase in speed then it is worth it to put the extra in and get it more optimized, the degree of benefit will outweigh the costs.
The thing that usually gets me like comments like this parent it assumes a completely Academic Computer Science approach to all problems. While real life requires making trade offs and sacrificing performance is often a good trade off to make because most of the time it is unnoticeable, most computers spend most of their time idle anyways, and most application are idle waiting for inputs. So in the once in a while heavy processing moment say in this case an HTML Render adding 1 second to the load in real life most people wont notice unless they are going back and forward button crazy. Or doing a batch rendering job. As for memory I am surprised that you didn't bring up the large quanity of 32bit systems still out there being sold as new only handling a max of 4 GB or RAM so for a large population RAM limits are an issue again.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
How about making at least the Javascript engine and the Flash plugin framework multi-threaded?
IE has been lowering the CPU priority of Flash applets for years so if you have 100 Flash ads open, it won't bog down your browsing. On Firefox, try opening a couple of tabs in Yahoo and it basically grinds to a halt.
It used to be that in NS4, I could see "nsplugin" process so I can renice that to achieve the same effect. On Firefox, it's not possible.
And, if you happen to leave Gmail open, my CPU usage (lowly Sempron) will hike to 30% twice a minute. On IE the CPU usage stays low. I suspect it's due to a multi-threaded Javascript engine in which individual thread can be prioritized.
All of the best programmers I know are lazy; it's the well-meaning hard-working ones who duplicate functionality, write large fragile functions to solve a single case of a generic problem, and who create difficult and obscure interfaces. Laziness encourages you to let the computer do those things that it is good at, encourages code re-use, and encourages using built-in features wherever possible.
The only case where you should be managing your own memory is in embedded programming or high-performance applications. Since TFM is about a *web browser*, neither of those apply. It doesn't really matter to the average person whether firefox leaks memory or not; they care if it is able to correctly render their homepage. It's a smart move for FF to have concentrated on Getting It Working first, since that's the constraint that will actually determine their product's success or failure.
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.
Real programmers can code memory leaks in any programming language.
:-)
(I'm not kidding, it is very easy to accidentally use a strong pointer, where a weak pointer should have been used. Especially in languages that doesn't support the later concept
You jest (I assume), but it is actually quite possible to code like that. In fact, in a previous job of mine part of the internal coding guidelines said "Don't use malloc".
There is a major difference though - the problem they were trying to solve didn't involve a user interface and didn't deal with data of undefined size - it was basically a large database app.
Of course, under the hood the compiler has to allocate memory at some point for more or less everything - but it's something the compiler can worry about, not the developer.
> 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.
Precisely. A skilled craftsman does not blame the tools. A skilled craftsman does the job right, and if it cannot be done right with the tools at hand, he/she goes and gets tools that are appropriate for the job.
Poor programming is possible in any language, and garbage-collected languages are no exception. I would also caution that garbage-collected languages tend to encourage more novice programmers because of the apparent ease of use (it isn't really easier). This results in a larger number of poorly-written apps by people who think they know how to write software. Taking away the need to explicitly manage memory just encourages lazy programmers who can always find something else to be sloppy about.
As for garbage collection making this sort of thing magically go away, that simply isn't the case. Working around garbage collection with things like "soft references" is a disgusting hack and is actually far harder than simply doing explicit memory management in the first place. Anyone who says differently has never had to manage any complex data structures that reference each other in non-trivial ways. The alternative is to basically write your own code that explicitly walks the data structure, deleting circular references, etc. If you're going to that much trouble, you are doing just as much work as you would for explicit memory management, but without the performance benefits from actually being able to destroy the objects immediately, and thus garbage collection is just hurting performance without providing any real benefit.
Basically, apart from the really trivial cases (most of which could be solved just as easily by simply creating a stack-local auto-destroy variant of malloc), garbage collection causes more problems than it solves. In my book, garbage collection in programming language ranks right up there with multiple inheritance as one of the worst ideas ever conceived.
Check out my sci-fi/humor trilogy at PatriotsBooks.
"They're not in denial."
Maybe Mozilla people are not in denial about that one technical issue, but they certainly have been about others. See Mozilla Foundation Top 20 Excuses for Not Fixing Firefox Bugs, posted to the story 611 Defects, 71 Vulnerabilities Found In Firefox.
Since that Slashdot story, many many memory leaks have been found in Firefox which have made it much more stable. But Firefox is STILL the most unstable program in common use.
> So have they finally acknowledged that Firefox is a memory hog instead of just blaming users
I have yet to see an actual Firefox developer blame users for memory usage issues. Anyone actually working with the code knows that there are problems that need fixing.
What I _have_ seen are fanboys who've never looked at the code making claims about what is or is not leaking without a basis in reality.
The fact is:
1) There are some leaks in Gecko
2) There are some leaks in the Firefox UI
3) There are some leaks in extensions
4) There are some behaviors in all three that are not leaks but do
lead to prolonged usage of large amounts of memory.
By "leak" above I mean "memory not deallocated until program shutdown", which is a looser meaning than the typical meaning of "leak" as "memory the program does not deallocate at all". In the end, the user doesn't care which is happening.
All four items above need to be addressed, though for item 4 there is the obvious question: is there utility from the user's point of view in holding on to that memory, and does that utility outweigh the memory usage. Put another way, a 5MB RAM page cache is clearly too small and a 500MB one is clearly too big (on modern hardware). The question is what a "good" size is.
> The memory buffers use up 3/4 of my memory with an empty, just launched, instance of Firefox.
You mean on Linux? A lot of that is disk buffering into RAM, right?
> but maybe I'm wrong
You're wrong.
> allocating buffer memory without even a single page loaded
To start a program you have to read it from disk. Linux in particular very aggressively buffers disk into RAM; it probably has not only all the files touched (not necessarily still open!) by Firefox as it starts, but various other programs you've started as well, the Firefox disk cache, etc, etc.
That may not be the case for all GC languages, but it is the case of what is perhaps the most prominent GC language - Java, which also has had the unfortunate aspect of being forced on a lot of companies because the programmers they could hire out of college didn't know any other language. (Sad reflection on the colleges and universities they came out of too - but that is also partly due to vo-tech colleges as well, where training is typically limited to the quick & dirty.) In no way was I assuming a quot;completely Academic Computer Science approach to all problems" - in fact, a lot of Academic Computer Science is strongly behind the GC languages and not teaching students how to manage resources.
What I am talking about is doing proper engineering of software - proper design, architecture, and implementation - such that the resources are managed in the program appropriately. It really is not a hard job to do, and when done - it can speed up implementation and debugging as it all works towards it in the end.
By doing the rag-tag job that Academic Computer Science pushes, debugging will be long and hellish, and will only add to cost over-run.
Additionally, I am primarily pushing management of resources in this thread, including memory. When it comes to performance, then yes - you need to run a profiler and optimize the program accordingly and not spend all your time on optimizing every line of code throughout the entire program.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
My experience has been quite counter to many of the complaining posts I have read. I now have nearly no lockups that I can ascribe to Firefox 2.0.x whereas it was very obvious that version 1.5 ate memory and at times locked a session. At last count I had 164 tabs open and it is likely nearer to 180 at the moment. At most times I have at least three sessions running email (Thunderbird), browser, coding with Subversion with several files open and in the last a connection to a remote server. If anything my system is much more reliable with 2.0 over 1.5.
I used to be a casual tester for both versions 1.5 and 2.0 and I switched to each well prior to their offical release. What I noticed was much more effort was expended creating satisfactory working versions on Windows over either the Mac or Linux. Nonetheless, I have been pleased with the results. My use of the coming version 3.0 has been very limited running of most of the stable alpha versions. So far my limited exposure seems to see an improvement over 2.0. Another factor that could make my experience worse, is that I use the Mozilla version that I install by hand. I have long ago not bothered to even update the supplied distribution version. Nonetheless, I have no complaints.
Another factor that should degrade my experience, is my machine's inners are not of that recent vitage having only one Gig of RAM and a much older AMD CPU. Might some of the problems so vociferously expressed here be due to other factors than so loudly proclaimed?
I am well aware that supposedly identical machines, with the same software can behave very differently. Had that experience with corporate property using NT and XP, where I could get to Unix and the version control system while a neighbor could not. Nonetheless, I find it odd that my experience is so at odds with the many that have written.
As a community service, I'm posting this list I made. When someone wants to use one of the excuses, they can just give the excuse number. That will save typing.
Mozilla Foundation Top 20 Excuses for Not Fixing the Firefox Memory and CPU Hogging bugs.
You realize, of course, you are seriously going against Slashdot groupthink here. Still, if I had mod points, I'd give you one. Macho programmers who think they are too awesomely skillful to screw up are the ones whose screwups always take me the most time to chase down.
Frankly if you can't look at a problem and then pull out five or six languages from your tool belt and evaluate which will be the best for this job, then you are a bad programmer. Don't code in C++ that which could easily be done in Python. Don't code in Python that which could easily be done in Bash. If you don't have a compelling argument for using C, DON'T USE IT!
Sometimes I think Java is awful for no other reason than companies tend to believe that using one language for other is a net gain. That has never been my experience except when your very best programmers aren't all that good either. If you insist that everything run on the Java runtime, use Jython and embed Python. A good example of multi-language gains can be seen with embedded Lua. There are many applications out there that use Lua "under the covers" so that things that do not have to be written in C++ aren't. This includes games (I believe WoW is one).
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
As another commentor points out, it is very true that performance does matter. Servers software must be very responsive and server admins care very much about the user perception of their server's performance, and the perceptive performance of the services they render.
However, while more tolerable on the user's desktop - it is still very important. User's don't like sitting around waiting for an application to become ready to use, or for an application to play catch up. That costs time, and for businesses that costs money. Simple things such as managing resources can often reduce that wait period to something more tolerable that isn't so costly but only when the programmer deploys such tactics and uses a language (GC'd or not) that allows them to do so.
Ever have a user complain that your program didn't respond fast enough? One good example for you - in one network I am on, there is no reverse-DNS lookups and some other network basics are not provided, this results in some programs not responding (both IE and FF) for up to 5 minutes if I accidentally type in a bad URL. This results in a user perceived performance issue with the application (my first thought, until I could show that the same problem did not exist on another network with the same machine) as the application locked up - user interface was not usable, and would not be repainted, etc. while the software waited. Now IE and FF could mitigate this by pushing that DNS lookup into a worker thread. While this is one example of an external issue affecting internals to a software program, the basis behind the issue - user perceived performance problem - extends quite far.
Few other examples - How often have you waited on MS Outlook to catch up with you? How often have to waited for MS Word to compete a task - that you didn't start - so that you could continue working on the document? How often have you worked on a document and had the computer stop responding to you while it finishes something else? How often have you upgraded Windows or Office to a newer version and end up having to upgrade the PC even though you didn't do anything different, and were not using any new features?
A Pentium 75 with 32 MB RAM should be sufficient to do basic email; however, try to do it with most programs these days and the system will feel like it was bogged down, even though you could do that and run Office, and more when it came out back around 1995.
Performance is a big thing, and the perception of performance is even bigger.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Although Firefox does have some issues with memory usage (and occasionally memory leaks), that doesn't seem the be the primary cause of usability issues.
In my personal experience with Firefox, I see two problems:
Both of these problems could be solved relatively easily with threads (in a number of different ways), but for some reason the Firefox developers have an irrational paranoia of anything that even vaguely resembles native concurrency. They say "the real problem is just response time, if we can respond fast enough in a single thread it's the same" - but then they never actually do it, and they definitely don't do anything that would let them recover from component crashes.
-- The act of censorship is always worse than whatever is being censored. Always.
No professional computer programmer should be incapable of programming without automatic garbage collection, just as no aeroplane pilot should be incapable of flying without an autopilot. You shouldn't be doing it very often, but you absolutely should have the ability.
I am trolling
While I agree with this sentiment on principle, in practice this has proven to yield unworkable solutions. Different people bring different skillsets to the table. You may have a dozen developers who all have C++ in common, but to varying degrees. One may be more skilled in Perl, another in smalltalk, another in Python, and three more in Java. Divvy up the specs and tell each one to "Write your code using the best tool for the job." Then spend another year trying to integrate the pieces, and when they quit try to hire someone who can maintain the hydra.
Picking a single language for a project (at least at the component level) is pretty much a requirement.
Even though they try to hand-wave it away, this has been a big problem in the Microsoft .NET world. When it was introduced, Microsoft promised that all .NET languages were equal, first-class languages (my interpretation at the time was that C# programmers were instantly demoted to VB programmers :-( ) and that a developer could write in whichever .NET language they were most comfortable. But there are C# programmers and VB.NET programmers who don't really speak each other's language, even though they all compile down to the same MSIL. Trying to get them to maintain each others code leads to a lot of squabbling.
It's easy to say "A good programmer can write in any of these languages" but in reality it's much harder to find a lot of good programmers that are both willing and able to competently do maintenance in all of the languages you might end up with.
John
Perhaps the culprit is C++. Languages with auto-garbage-collection or are database-engine-based tend to clean up automatically or cache to disk more effectively. C/C++ just seems to have so many low-level crevices to accidently mess up with.
...) which does so. If this occurs in the base class of a derived class with member variables which are pointers, the latter aren't initialized and contain leftover heap or stack junk. So the garbage collector can go awry and get totally lost.
Like C, C++ gives you more than enough rope to hang yourself.
C++ has four memory models for object instances:
- Global/static: (permanent one-per-program instances).
- Stack/locally scoped: (local variables of class type in functions/subroutines or limited scope (between curly-brackets) within them.
- Member/class scoped: (non-static variables of class type which are members of another class.)
- Heap/dynamic: (created with "new" and released with "delete")
The programming model for management of dynamic memory is algorithmic: The programmer is expected to keep track of when objects are no longer reachable and free them.
C++ provides enough hooks to construct reference-counting smartpointers that can delete dynamic instances when their refcounts go to zero. But reference counting isn't a general solution: A set of mutually-referencing objects can become disconnected. They can no longer be reached and should be freed. But each references another, so their reference counts are non-zero and they persist. This is why garbage collection requires full-blown forest-walks (or incremental partitions of them) to reliably avoid memory leaks.
Unfortunately, C++ has a subtle bug in the specification (and standards) that prevents building a general garbage collection system within it (even with preprocessor assistance).
The problem is that garbage collection is one of the ways that an external routine can (properly) call a virtual member function (or do the equivalent) on an object that is midway through its construction or destruction and absolutely must get the correct version of the function for the stage of construction in question.
This occurs because an object can have pointers to heap-allocated ("dynamic") objects as variables at multiple levels of inheritance. To build in a garbage collector your objects need a way for the collector to identify their pointers and follow them. Anything that allocates memory may provoke it do to this as a side-effect, and routines called during construction (or destruction) may allocate memory, or call something (that calls something that calls something
To avoid this you build heap-allocated objects (and those which point to them) so that they contain a virtual function that enumerates the pointers in its own level (and those more baseward) and override this as you proceed through the stages of construction, so the pointers at each level are enumerated only IF they have been initialized. (There are constructs other than garbage collection with similar issues, and for some of them the issues are also significant on destruction, as various levels are finalized and their virtual functions would no longer perform correctly.)
C++ actually gets this correct during the execution of the objects' own constructors and destructors themselves. (Other OOP languages, such as Smalltalk and Objective C, don't. Smalltalk gives you the "subclass" version during the construction of all the levels of "superclasses" - thus breaking the debugging of the superclasses whenever you override a method that is used in a constructor. It gets away with garbage collection because it's built-in and handled separately.)
Unfortunately, member variables of object type also have construction and destruction, which might provoke garbage collection (or what-have-you) as a side-effect. During the construction of members you're guaranteed to have times when other members are not yet initialized - which ma
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Firefox already has a garbage collector for detecting memory leaks. (It's only used for debugging.) Of course, it probably doesn't help much when JavaScript objects create circular references with C++ XPCOM components, which are reference counted. Those circular references are the main source of memory leaks (or object leaks?) for Firefox. It's very easy to create them, and many extensions are very bad about creating lots of them.