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++;
This is what has been keeping me off Firefox on my memory-lacking iBook.
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
Are there really any memory problems that cannot be cured by strict adherance to the rule of "allocate memory at the beginging of a routine, deallocate same amount at the end"?
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.
Ok.
Well, it has never been successfully tested.
Actually... it kinda is :)
.exe in order to save my session tabs and free up the memory. Every single machine I use (3 desktops, 1 laptop) has to be forced down on a nearly daily basis if not more, in order to keep the memory available for other applications.
This is long overdue and is the cause of my biggest gripe with Firefox. Without a couple vital extensions related to my work, I would have ditched FF for IE7 because of this issue. I absolutely hate having to Force quit the
Invexi - a Phoenix, AZ based web design and web development company.
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?
Who said restarting the computer? What do you call quitting FF then opening it again?
On my Mac, if I leave it running with Firefox open for a few days I eventually have to restart it -- the whole computer, not just the program -- because it runs completely out of disk space. I've got about 1.7GB free normally, but Firefox (at least, I think it's Firefox; I haven't done formal, rigorous tests but I'm reasonably sure) eventually churns through enough virtual memory (even though I have 2GB of RAM), temporary files, or something that it uses up that entire 1.7GB. Quitting Firefox doesn't delete the temporary files; only restarting the computer does.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I haven't tried it myself, but would this be a temporary cure? http://www.freerepublic.com/focus/f-bloggers/1327586/posts
www.opera.com ;P
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-
Whoa, let's not go crazy here!
Sir... Sir.... SIR! Put down the mouse and back away from the browser!
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
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.
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.
On that note, Firefox 3 now asks if you want to save your session when you choose quit out of the file menu, or when you close the last window with multiple tabs open.
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...
Note to self: Stop putting jokes in my insightful comments so I can get something other than +1 Funny!
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.
One of the things they're adding is a time-based cache for unused images. For example, if after 5 seconds an image isn't used, it's freed from memory. This alone gave them a huge memory boost, IIRC.
What's so special about memory management that you can't encapsulate it in a dedicated module, and abstract it away in the form of, say, a garbage collector?
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
My notion is that if you're finding yourself doing a lot of new/delete statements, it's about time that you considered using smart pointers instead. Why should you have to remember to deallocate memory every last time you outscope some object when you can have the object do it for itself?
Ever since, I've been suspicious of Jesus and very careful around chlorine.
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)
I agree. In reality, who needs a "full featured" browser, and when/where do they need it. At home, if I'm surfing around the various "portal" sites I use to collect my information (google.com/ig for instance), I could deal with a minimal browser. In fact, I may go look around for something pretty lean when I get home tonight.
However, here at work, I am frequently sent off to various vendor sites and need a "full" browser that is able to process flash, java script, etc...
I use a browser launched VPN client. And I in fact always have IE open for that and Firefox open for use as a web browser.... I have to restart Firefox at least twice a day to keep memory utilization reasonable and it's a pain to have to reauth. I really don't care *what* causes such horrible memory leaks (but it must be either Live HTTP Headers or Web Developer in my case) but the thing sucks up 350-500mb after a few hours of use.
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 poorly programmed Java application can leak memory too. The culprit is likely not C++; the culprit is more likely poor programming practices or programming errors.
That's a bullshit excuse they've thrown around for a while, and it's simply not true. You can turn the memory usage on those features down and firefox still slowly creeps up to using as much memory as it can, and this is without any addons whatsoever. So, either firefox ignores configuration settings or it's a memory leak.
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.
]{
As a programmer, it is your job to think about both aspects. Anyone can think about the "big picture" after spending a year or two at ITT Tech. Real programmers make the big bucks because they can translate that "big picture" into an algorithm that "moves individual bytes around". Good programmers make even more money if they can do this without crashing the system or running it low on memory while following a strict time schedule.
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.
Frequent restarts of things on my computer make me furious. I can't imagine why anyone would tolerate such things.
Because other browsers have their problems too, and I have to web browse with something.
I disagree. You can, in fact, write any piece of software in assembler. The obvious advantage is that it would be much smaller and faster than any other solution. The challenge is that this would be time consuming and would require a very skilled team of developers to do correctly. This would, in turn, drive up cost dramatically.
In other words we build software with increasing higher level languages not because it is not possible to build software with lower level languages but because it much cheaper to do so.
]{
I agree with all of your comments about not wasting computing resources, but I'm not sure they are apropos. Firefox is not written in Java. Firefox is written in C++.
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.
Amen to that. I get that exact same mantra from Java developers all the time. And, unsurprisingly, amazingly simple programs end up amazingly bloated. Most tomcat apps, especially, are great examples of this.
And another thing about Java: for a "cross-platform language", it really has an awful lot of problems running between different versions of itself. Sun Java or not? 1.4, 1.5, or 1.6? I once even had to use a program that had a compatability issue between 1.4.2_04 and 1.4.2_07! I'm not just talking about forward compatability, but backwards compatability as well, forcing me to keep multiple versions of Java on my system as a consequence. It doesn't give me a very good impression of the language.
If your concern is memory leaks, just use C++ and smart pointers.
Ever since, I've been suspicious of Jesus and very careful around chlorine.
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!
The take-home message is fairly obvious, though sometimes forgotten: reducing memory usage will often yield speed boosts also.
I'm sure it's part of the problem. I wish Firefox's JS implementation were as fast as Opera's, or even IE's. Its GC makes it jerky as all hell. Like, just now, as I type into this dialog box.
It's a step in the right direction, but it's still a bad UI. A good UI should not ask for permission for anything that can be undone. It should automatically save the session, and then give you an option of reopening it the next time you launch. Safari 3 does this, although it hides the reopen function in the History menu, and doesn't save the back-history for each tab (irritating). Restarting it every few days keeps memory consumption sensible (I just restarted it, and it went from 400MB to 70MB). There's no conceptual reason why the browser couldn't detect that it's not active, has been running for a few days, and hasn't been active for a few minutes (or hours) and automatically restart itself periodically. Think of it as a very coarse-grained version of garbage collection.
I am TheRaven on Soylent News
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.
If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!
Assembler programmers used to make the same claim. I am not saying better languages will make bad programming go away, but they may take some of the pain out of decent programming such that people may be more willing to to help out. OSS depends on volunteers, and the more that can be done per volunteer, the better the software will be.
(As far as Java, some complain that it should allow more "hints" about when and where to do GC rather than rely on the run-time engine alone. That seems like a good compromise.)
Table-ized A.I.
Cautiously avoiding the mention of anyones favorite O/S so as not to earn troll mod points; It all depends on where the leaks are. The only way to fix some of them would be to build a staticly linked executable. That still doesn't get you around kernel/driver bugs. In my experience, many apps that appear to leak quite badly on one system do very well on another.
Hint: Try setting "LEAKS=OFF" in the registry. ;-)
Have gnu, will travel.
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.
I'm not seeing the connection between architecture and memory leaks, particularly in a language like C/C++, where simple and subtle coding errors (that have nothing to do with architecture) can make all the difference.
"The problem with internet quotations is that many are not genuine" -Abraham Lincoln
Well, seems like this is time to extol the joys of the C and C++ language, with their delightful scavenger hunt the whole team can play: Find the Memory Leaks! Seriously--can you imagine a more embarrassing thing for the developers of Firefox? You guys were so sloppy that we're expanding the hunt for your mistakes to a world-wide level. Gosh, they must be proud of their work.
Firefox does indeed crash sometimes. On my system, it can run for weeks without problem, but certain types of content (e.g. YouTube) can crash it if it's been open that long. There's no good excuse for crashing: these problems absolutely should be fixed.
It should be noted, however, that the "session restore" feature in Firefox 2.x reduces the impact of these crashes considerably. If there's an unexpected crash, when you reopen it, you get a dialog that says "Do you want to restore your previous session?" So, you actually don't lose any of your tabs. (Even session-dependent things, like being logged in to Gmail or entering something into a text field are restored, if memory serves.) So a crash is functionally identical to a 2-second freeze.
Again, I emphasize that the crashing should be fixed. I'm not excusing the bugs. However, it's nice to see that they have at least coded it such that when it fails, it fails somewhat "gracefully."
The truth is that as fine a product as FireFox is, it's "ownership" has issues with criticism from the hoi polloi. The reason this is an issue is that FireFox sells itself as a browser for the masses, not just a "leet" geek toy. Therefore, one would expect the FireFox leadership to be responsive to the issues that the "masses" have with FireFox. This has been an issue in the past.
If you want news from today, you have to come back tomorrow.
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!
Exactly my point. And on the scale of applications the size of Firefox, OpenOffice or any other reasonably large application it would take an impossible amount of time and money to create them in assembler. Ergo, it's not feasible. High level tools make larger software possible, and automatic garbage collection is one of those tools.
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.
IIRC, "there are no leaks in firefox, it is your extensions causing the problems".
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
If I am doing something serious wrong with my Firefox, then it is not my fault. I am using the browser no differently then thousands and thousands of other users. I visit dozens of websites a day, opening and closing tabs regularly while online. That simple use causes the memory to run rampant. Maybe it is the extensions, either way, FF should not allow an extension to compromise the integrity of the memory allocation on my machine. That is assuming an extension is the main issue. I do not believe to be true since I have a cocktail of extensions on this machine while my laptop has only a few, yet both have the same performance issues. I have one machine with a clean and updated FF install, no extensions, and I still see this problem, though not as often since it does not see regular use compared to my other machines.
Invexi - a Phoenix, AZ based web design and web development company.
Yes, I sure hope that I won't have to deal with massive memory usage anymore: http://moore.cx/images/firefox.png
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.
And when everyone finds themselves writing a lot of new/delete statements, it's about time they start using a language that has smart pointers as the default option (or at least as an option that's just as easy as regular pointers).
Well, that's one thing that Java did and got right, as much as it pains me to praise the language.
Of course, if you're allergic to garbage collection by default, you could have a garbage collector that you link in during debug mode that records everything it collects, along with a stack trace showing where it was allocated. That will show you very quickly where your memory leaks are.
There are valid reasons to want to avoid garbage collection. Mainly that it's an action that takes place at uncontrolled intervals and takes an unbounded amount of time to complete.
Smart pointers are still a smart thing, for all those cases where it really is so simple that it's ok to deallocate when you leave the current scope. It won't stop you from fine-grained control in all the cases where "real" memory management is needed, rather than some simple scratch space that you don't want to allocate on the stack.
Opera has significantly more features than Firefox does without some extensions installed, yet Opera definitely isn't a memory hog.
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.
So have they finally acknowledged that Firefox is a memory hog instead of just blaming users for not understanding features? I can't believe how much memory Firefox uses just from the start. The memory buffers use up 3/4 of my memory with an empty, just launched, instance of Firefox. Where does all that go? Sure buffers can be cleared if needed, but I'd rather have that memory free (which I'm guessing can be allocated more easily than buffered memory, but maybe I'm wrong). Either way, I'd like to know why it spent time allocating buffer memory without even a single page loaded.
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.
Java has automatic garbage collection and many applications still leak! Eclipse is a good example. I do Java Servlet development using Eclipse and WST. I can't do serious development for more than about 6 hours without Eclipse running out of RAM and promptly either freezing up or exiting. GC is no panacea. Sure it can make some things easier, but if the programmer has the code hold onto things that will never be used, GC won't help.
Another example: at my previous job we used Java to create applications (no web stuff, just plain CLI apps.) GC became the problem because of the high allocation rate. Rewriting in C++ where we used smart pointers improved the performance 2-3x, mostly owing from the lack of GC and copious use of stack-based objects. Memory leaks were few and far between for us owing to a good architecture.
I don't know, but it works for me.
Professional computer programming, perhaps. Professional software engineering, definitely not.
If this is said in the context of writing an application, desktop or otherwise, that is intended to be run by someone other than the programmer or his immediate organization, then it's a terrible approach to the problem. But if you're writing an app that is intended to run solely on your company's application servers, it's perfectly reasonable to say that developer time costs more than the number of app servers or extra ram that it would take to deal with the quick-and-dirty solution. When you have application servers behind a load balancer, you're basically able to add application servers as the need arises. There isn't the same need for tightly-coded, memory-efficient code that there is when you're code is being run by third parties.
None of this is an excuse for sloppy programming that could easily be done better with not much more effort. But if the effort do it in a resource-efficient manner really is significantly more than it is to do it in a simpler fashion, then it's perfectly reasonable to pick the easier route.
It's a question of the type of memory issues that arise. If you have a minor memory leak in a simple function in the context of a good architecture, both finding and correcting it should be trivial. If you've spent proper time in the architecture to account for memory management, you should have architected in solutions to application-level memory management, leaving only low-level management to be a source of problems- where those problems are not difficult.
Basically, not all memory leaks are created equal. Correct architecture prevents the "hard" classes of memory leaks, leaving the "easy" classes that are really no more difficult to find/fix than anything else.
The ringing of the division bell has begun... -PF
Use Haskell. It's a purely functional language, so no variables, no garbage, nothing to worry about :)
Ignoring, of course, that assembler still sits comfortably above machine language and microcode, both of which are at a much higher level than the gate logic that defines them. All this whining about "your arbitrary abstraction level is clearly inferior to my arbitrary abstraction level" is just silly.
Dewey, what part of this looks like authorities should be involved?
In this case, I think it's a good idea to warn the user before saving the session. The user may not know about the feature, and Firefox might later be opened by someone else. If you want it to save the session without asking, choose the 'always do this' option and then 'save and quit'.
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.
Must be something else. I run Firefox 2.0.0.7 under Windows 2000 on a ~500MHz laptop w/ 160MB of memory, and it doesn't ever lock up on me. No, it's not fast, but it's quite stable and usable (in spite of the 800x600 max resolution). Something else is likely the cause of your instability, like a plug-in or using a later version of Windows.
Method of processing duck feet
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.
Agree! And you know what was even more irritating than the official leadership denying this? The dozen Slashbots who would automatically throw themselves sacrificially onto the incoming path of your criticism, saying, "There's no memory leak! Firefox is just reserving 3GB of memory to
cache all your huge web pages! Like that bloated Google main page!"
And now Mozilla is saying, "You know that memory leak that didn't exist? Well, we're fixing it now." Did someone take lessons in Microsoft Marketspeak?
Here's something else they should stop denying: the fact that Firefox is frick'n bloated. It needs to be pared down to a skeletal size, and everything moved to an official series plug-ins/extensions/add-ons (or whatever they're called these days) that can be installed by default, but which can be removed to get the desired responsiveness and small memory footprint. But when Chris Beard of Mozilla was interviewed on Slashdot, he said:Yeah, buddy, that's because all your extensions are an integral inseparable part of Firefox. You're just afraid of the complexity of testing and debugging extensions, aren't you?
I still use Firefox. I still use unsigned extensions because that seems to be the standard, and for some extensions there just aren't any signatures. That's because Firefox has Adblock Plus and NoScript. The minute these appear in Konqueror, I'm saying goodbye to Firefox.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Note that even GNU GCC uses a garbage collector. There is nothing wrong with using a machine to handle memory management and with C++ it is the only reliable way.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources,
People keep saying this. I wonder if it's true -- I haven't seen any evidence of it. I've seen lazy/stupid programmers in all kinds of languages. Wouldn't the same argument work just as well against memory protection, and preemptive multitasking, and compilers?
and in some cases even prohibit the programmer from being able to manage their resources.
That's a problem with your specific GC, not a problem with GC. JWZ even ranted about this. You hear Java users complaining about memory, and Java programmers bitching about the GC, but you never hear Lisp programmers bitching about their GC. Any production Lisp GC gives the programmer far more control than Java's does. Hearing people rant against GC is like hearing Yugo owners rant that automobiles suck.
C/C++ and similar languages, on the other hand, force the programmers to manage their resources.
No, they don't. How would they? If I forget to free something and it goes out of scope, bang, memory leak. How am I forced to do anything about that by the language? (I've heard more than one story about somebody who learned Java, and then went back to writing C++, and wrote many lines of code before remembering that their C++, while correct, leaked left-and-right.)
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.
You're right. The easiest route to fast, working software is to get it correct, and then tune for performance -- and GCs are great for that.
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). [...] But in either case it doesn't get done unless the programmers do their job, and use tools that allow them to do it.
Again, you're right. And these requirements just scream "we need a GC that doesn't suck".
> in some cases even prohibit the programmer from being able to manage their resources.
There you have hit the problem with garbage collection.
A lot of people don't realise that it's easier to have memory leaks with languages with garbage collection. In a complicated program typically each object is referenced by dozens of other objects and you have to carefully check that each one is nulled out, otherwise you will have "unintentional object retention". In c++ a well designed program will have a clearly designated owner of each object, which is reponsible for deleting the object.
I think it's called Firefeature, though.
If you use a garbage collector, you're deciding that it's worth a small performance penalty and a memory footprint that's slightly higher than optimal, and in exchange having vastly fewer memory leaks than is otherwise likely.
Well, sometimes not that small. You have to keep in mind that collection is far from free. At a conference I attended recently, there was a talk on avoiding garbage collection strain with certain applications using array slicing -- which basically works out to pointer aliasing, with the caveat that the alias can fall anywhere in the range allocated to the original pointer.
Still, I'd rather work with a garbage collector than without. I can be clever and use those techniques to reduce the work that the collector has to do, but if I screw up -- and no matter how good I am, I will; and when I do, it's going to be damned hard to find -- the garbage collector will take care of that.
For you, try a garbage collector that records a stacktrace for each allocation, and when it collects, log how much memory was allocated and where. Much faster and easier than hunting down memory leaks manually.
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
Those languages that have automatic cleanup also tend to have a larger memory footprint in the first place. There's a reason C++ is around. When coded -properly- it is faster and more efficient than these magical languages you speak of.
"Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
I know this is not code level, technical, observation but a real world comparison. I use 4, 22in LCDs in my real estate office window to advertise houses. The web page they display is javascript light, one to change the logo every 30 seconds. Each page has FLIKR applet to show a slide show of the property. The 4 firefox browsers will grind the system to a halt within 3 days (P4 630mb of RAM). The same 4 pages shown continously in IE7 will last 8-10 days. Either way it is crap b/c they should not leak at all, they are web browsers with thousands of peole wokring on them. Increased quality review and assurance of core functionality would probably help here. Thankfully memory is so cheap I am bumping up to 3gb. Not to go quicker but to last longer between re-boots...
If I had mod points, you'd get a funny!
Are the moderators asleep today?
> (so much for the "millions of pairs of eyes" thing, huh?)
The story is about how many leaks have been found and fixed. How do you see that as a bad thing? Or do you mean that with open source development model, these bugs shouldn't been there in the first place? Well, Firefox is based on Mozilla Application Suite, which is based on Netscape Communicator, which was developed as closed source application, before it's source was released in 1998.
http://en.wikipedia.org/wiki/Mozilla_Application_Suite
> 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.
Add some threaded (or better threaded) support... I'm sick of one tab loading something like a Flickr.com page and while its loading I'm looking at other tabs and unable to scroll up and down the page...
The culprit is the designer choosing the wrong tool for the job. C++ is a SYSTEMS language where you want control of memory allocations at that level, not applications language where you don't need this kind of control.
http://www.rense.com/general79/wdx1.htm
Any type of liquid damage voids my service contract.
> What's so special about memory management that you can't encapsulate
> it in a dedicated module, and abstract it away in the form of, say,
> a garbage collector?
You're kidding, right?
The ONLY garbage collector that sort-of works the way you're suggesting -- and I mean ONLY -- was written by some guys at macromedia with extremely brass balls. I mean, big ones, that hit your knees when you're walking and trip you if you're trying to run fast.
Download the source for Tamarin. You'll see what I mean.
In the meantime, think about this ONE problem: How can you tell in C if a pointer points to memory which can safetly be freed?
Do daemons dream of electric sleep()?
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.
A memory leak is a programming error, an implementation failure. Complexity is not an excuse for the existance of errors at the implementation level, because can be easily avoided with proper programming methodology.
It is a shame that we assume that a complex application has to have memory leaks! I am sorry but after 30+ years of programming I cannot accept that kind of statements as being 'realistic', they are just 'sad'.
Users don't create memory leaks, only BAD PROGRAMMERS do.
What's in a sig?
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.
Comment removed based on user account deletion
You know everything you said would be true, IF our job was to squeeze the last bit of performance from a machine. But it's not. Our job is to enable the user. A programmer focusing on low level bit shifts, memory storage, string management, etc, takes his eyes off the truly "big picture" and that's the domain you are focusing on and the "business" problems there in.
Our users want results that provide them with real value, if performance is part of that value then so be it. Use the proper tools for the job.
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.
It's not as user friendly, but you can block ads with the host file. It'll work with any browser, or any program for that matter. http://en.wikipedia.org/wiki/Hosts_file
"A witty saying proves nothing." - Voltaire
> Since TFM is about a *web browser*, neither of those apply.
Actually... a web browser _is_ a high-performance application. You should see the rendering tasks that web sites toss at it and expect it to perform quickly and perfectly
C++ yields superior performance and memory usage, than higher level languages, in the hands of a skilled C++ programmer
OMG! Newsflash: lower level languages more lean and efficient than higher level languages. News at 10!
Lower level languages take more time and skill than higher level languages, resulting in increased developer costs and longer time to market. News at 11!
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Amazing... Last week when the huge gaping security holes in Firefox were discussed, I was heavily modded down for stating that between that and the huge memory leaks in FF, there was absolutely no reason not to just use IE.
The funny thing was... people claimed I was making stuff up about the memory leaks. I guess this one will get modded down from people denying FF has horrid security. And in next week's FF security article, they will deny the memory leaks. And so it goes.
If you're on a unix system, there are two very nice browsers that I know of:
Dillo runs on X and uses gtk 1.2 as a toolkit [oldschool]. It doesn't have a lot of features [hell, it doesn't even do CSS], but it's the leanest, fastest graphical browser I've ever used that integrates at all with other X applications.
Links2 runs in the terminal or [with the -g options] under X. The X version is ugly and doesn't integrate with other X apps, but it works incredibly well and even has support for some more advanced features like Javascript, which of course can be disabled if you like. I frequently run links2 on my laptop with limited memory and, while it may not be as pretty as Firefox, it definitely gets the job done more than 95% of the time.
That's a load of crap. People used to create full-featured applications in assembler all the time. The initial transition to higher level languages like C was mainly for portability, not for ease of programming; it's almost as easy to code something in asm as it is to code it in C, provided that your assembler supports certain critical features like labels for jumps and load/store addresses. The move towards higher level languages for ease of programming is a much more recent thing.
Back in college, I wrote 30+ pages of x86 asm in about 8-10 hours, complete with complex data structures, user input via BIOS, etc. It really isn't as hard as people make it out to be. It just isn't very portable, and thus isn't very practical for most purposes.
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.
A primer on this subject Thinking Forth.
vi +
In my day, we called that a stack variable. I don't see anything "smart" about it.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I found I had less rendering problems with Opera than with Firefox. I would have stuck with it at the time but Opera didn't support the built-in ghetto gTalk on the GMail website.
Now this was probably a year a go I tried it... So there is a fairly good chance I might be talking out of my ass now.
I Like Pie...
If I can run ff on my 2001 HP laptop,wiht a messed up harddrive with my own install of Windows 2000 on top of Windows ME, ff performance aint the issue.
/.ers reading this can add other features, like builtin support for video (the videolan thing doesn't work very well) ....
worrying about a little performance is a classic geek mistake; people buy features, not performance.
what are features ?
I have poor vision, and Cntrl+ doesnt increase the size of the text in the url window
the poor state of organization of the site where you down load extensions
I'm sure all the non geeky
Or how about better export and save of urls
or
or
remember, people buy features, not performance - if that werent true, how would MS rule the world ?
On a lot of the sites I tend to have tabs open on, my sessions will have expired, and the tabs are pointless if I restart the browser. If Firefox did that automatically it would make the frequent restarts (I tend to restart a couple of times a day - when Firefox reaches 1.5GB to 2GB of memory on my Macbook Pro) even more painful.
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)
Trying to pretend this isn't a Firefox problem when it's the only application that cause this problem for me and a lot of other people won't work.
Sometimes our job *is* to queeze the last bit of performance out of the machine, typically the desktop client-side apps don't care so much as you have RAM and CPU dedicated to 1 user, but the server is a different matter and requires a better approach. The user is not enabled if he has to spend seconds watching the cursor spin every time he clicks 'next'.
Bullshit. Its not different than using someone elses HTTP library instead of writing your own. You may want to spend time writing lots of needed, but non-productive code, but others of us want to more quickly build reliable applications.
Garbage collection doesn't mean you throw good coding out, but it does save you from forgetting to delete an object in memory, an error that can be very difficult to track down and for which we have a reliable solution.
That memory usage is mostly leaks. Whenever I get Firefox to 1.5-2GB, and close down all tabs, so my only page open is about:blank, and I clear out my cache, and tune the Firefox settings to minimize caching etc., most of that memory never gets freed up.
Now, it's certainly true that there's a lot that could be improved to reduce memory usage further, but I'd be perfectly happy just to get rid of the leaks. It's not like I regularly "need" to have 80+ tabs open, and even if I do, my machine is perfectly usable with 80+ tabs open initially after a restart if/when that is what I want to do, and I'll still have plenty of memory free.
A lot can be learned about programming by managing ones resources, and the programs will get better for it too. I'll give you that - and perhaps a good solution is to have the ability for the programmer do specify it even with the GC being there. However, at least for Java - there is nothing in the language itself that enables a Java programmer to even tell the GC that the memory block is available for de-allocation, the GC just has to guess and eat a lot of overhead to do it.
As for Lisp programmers, they are few and are usually Lisp programmers by choice. I know I certainly wouldn't punish myself with Lisp. (Yes, I've programmed in Lisp before.) You're forced to by the program not running for the required amount of time. If the program doesn't function, and crashes you'll have to track it down and fix it. You can make that easy on yourself, or hard on yourself depending on your approach; but having some algorithm follow you around and try to guess when you are no longer using a chunk of memory is not a solution - it's laziness.
To make it easy on yourself, you'd design the program to have entities that would be responsible for the memory - both for its allocation and de-allocation. I've done this. It works, and no GC is required either.
Moreover, I have written programs that stay up for a long time, and are good about their resources. And I'm done programs where I had to import legacy code that wasn't good and added such capabilities to them too so that they became good and solid - in the end, those programs were more solid than the OS, as the OS they were on was more likely to be rebooted before they would reach any kind of level that would be an issue.
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.
The problem, of course, is that the computer cannot do it automagically. You can leak memory in a GC language just as easily. The only difference is what causes the memory leak: In non-GC languages it's forgetting to use free(), in GC languages it's forgetting to null every reference to that memory (or at least every reference which isn't itself in unreferenced objects).
The problem GC solves is not memory leaks. The problem it solves are dangling pointers/references (i.e. if you have a non-null reference, with GC you are guaranteed it points to a valid object, while in non-GC languages it might point to a freed object, or even into some other object allocated later into the same memory).
The Tao of math: The numbers you can count are not the real numbers.
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)
And then you sometimes have a manager or client saying "this will be done in Java" because its what they want for some reason. Then you as the programmer are forced to use Java and may be unable to change their minds despite the downside of not being able to manage your memory, when you normally would.
There are certainly reasons why people use things that go beyond the choice of choosing a GC. They may not have opted to for that higher memory footprint, or performance penalty, but were at the hands of someone else that didn't know any better and were unable to convince them otherwise.
Your other points are of very true, and often overlooked by the GC-supportive crowd and Java supporters. I wouldn't say its "damned hard to find". I've done it in the past by having a small stack tracer I could use and turn on and off. I would use for debugging, and turn it off (removed from the compiled code) for production. But all it did was tell me where my memory leaks were. Worked pretty well, and the program it was used in was very solid. The only leaks I couldn't remove were OS API based. Additionally, it was very easy and quick to locate leaks on account of 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)
Same here. "Your computer is running low on disk space". Reboot computer, 1.5GB free.
I actually just reverted to firefox 1.5 on my powerbook (thank you http://mac.oldapps.com/firefox.php), so we'll see how it goes.
Check out my sysadmin blog!
A 10" Hitachi Sliding Compound Miter Saw with the laser sighting has a slightly different approach to that of the 10" DeWalt Sliding Compund Miter Saw without the laser sighting. The operator is the same. Don't blame either saw [either programming language--you choose the languages for this analogy] when the dimensions are short or long or the ends aren't orthogonal/square, etc. Blame the operator.
A computer, by definition, 'moves bytes around'.
No. A computer, by definition, computes. At one level, this consists of moving bytes around. At another, it consists of moving bits around. At another, it's electrons flowing. At another, it's symbol manipulation. I'm a programmer, and even I don't care about bytes, or electrons; if Firefox worked by black magic, I would not care.
If C++ is efficient, isn't assembly even more efficient? C++ isn't as good at dealing with individual bits as assembly. Won't somebody think of the bits?
But even Linux is written in C, rather than assembly, today, even though Linus is skilled at writing assembly language. Is it less efficient now because it has less assembly than Linux 0.01 did? No, it's more efficient because Linus and friends can deal in useful abstractions. If you tried to write Firefox in machine code, you'd never finish.
It sounds relatively safe to say "C++ yields superior performance and memory usage" because in one extreme case (say, an embedded system) it's true. You wouldn't use a GC there. But then, on a small enough system (say, 512 bytes of RAM) you wouldn't use a normal C library, either. There simply isn't room. Write your own. But this doesn't scale: on a gigabyte+ system, it's a net savings to use an existing (shared!) library for string manipulation, and it's a net savings to use an existing GC for memory allocation.
I HATE that damn dialog box!!!!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
You don't even need a GC to keep track of stack traces, build in debug mode, and then take snapshots of your code. You can quickly see which bits are leaking as the allocation count from the same place will go up and up and up. Microsoft's UMDH is a good tool for this.
Im not convinced GCs are good, if Java had better scope for objects, so the finaliser could be called deterministically for locally defined objects, then yes it'd be good. (a bit like IDispose hack that MS put into C#, but properly done with full language suport instead of being a bodged-on hack)(which reminds me of Finalisers in the first place - when I was first shown Java at a conference by IBM at Hursley Park it didn't have finalisers, everyone in the conference basically said "that's a bit pants", a few months later Sun bodged finalisers onto the language).
The biggest problem with GC is that they only consider memory, no-one really stopped to think that it's used to clean up objects that hang on to more precious resources.
This is very true.
However there are some things in Opera that I can't or don't know how to change that drive me nuts, and I stop using it after about a week.
Like,
I am a serial tab opener. Middle click is like crack for me. When I go to a tab that I've opened, and read it, when I close the tab, I want to go to the next tab, not the previous tab. The next tab to the right, the next one I opened. Argh!
Also, on Linux (ubuntu) I have weird issues with flash not playing correctly, and it works great in Firefox (for a few hours, till I have to kill -9 firefox-bin, that is).
Check out my sysadmin blog!
You can't forget "yea, but what extensions do you have installed?"
Check out my sysadmin blog!
Why do you think a C++ programmer has to focus at low level shifts, memory storage, string management, etc? Maybe you are not aware that there's a standard library which liberates you from those needs?
The Tao of math: The numbers you can count are not the real numbers.
Google Talk works in Opera.
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)
Actually I am well aware of those things being a C++ programmer myself. The Parent post referred to C++ as superior because it didn't provide these "crutches".
Yes, hence my line "use the best tool for the job". My job as a programmer is not to squeeze the most out of a machine, that's a byproduct of my abilities. My focus is always the domain and the user.
> If your concern is memory leaks, just use C++ and smart pointers.
_now_ I'm concerned about memory leaks.
Smart pointers don't solve all memory leaks/problems. Most don't detect circular references and even if they do (as Java's garbage collector does) everything still isn't fixed. People often forget to null out pointers no longer needed. While not technically a memory leak, it still eats all your memory.
At least Java has weak references which do not prevent the object from being garbage collected and are auto-nulled when it goes, and optionally get added to a notify queue. Very useful for implementing collections :).
But solving dangling pointers has the added effect of making memory leaks less likely to occur. Without GC you have no way of knowing if a particular object/memory area is referenced by someone else, and as such risk either a dangling pointer or memory leak no matter what you do. Yes, there are ways to work around this - strict policies on who "owns" the object, smart pointers with reference counting, etc - but they they are ultimately just bandaids. By making dangling pointers impossible GC removes the problem of when to free the memory, which makes memory management a lot simpler.
This is especially important for open-sourced programs which tend to grow organically over time, with developers coming and going. If even one doesn't know about a particular memory area ownership policy, the end result is a bug. Of course the same is true for any large enough application: as soon as you have more than one programmer, there's a possibility that they fail to adhere to the same policy and cause all kinds of fascinating bugs.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I've forgiven them time and time again for screwing up.
First it was the MNG/JNG farce - you have to see this for yourself to believe it. 5 years (!!) of making up bullshit excuses later they dump an inferior, crippled "replacement" format in the browser to force everyone to give up.
I won't comment on their side project to make a faster, smaller, less bloated browser... you can all see what a success that's been.
Now for some reason despite all the times the mozilla people have done this -- much more than the two examples I've mentioned -- I was still using Firefox last month. Then it broke spectacularly on me (which was to be expected given it was a CVS build), so I load 2.0 up again and I realise half the extensions I have installed in it are to fix bugs and security holes it shouldn't have in the first place. I can name Noscript and Long Titles off the top of my head. I realised there was no reason to keep using this crap just like there was no reason to keep using windows.
Memory leaks aren't Firefox's biggest problem -- it's the inmates running the asylum that is. Until that's fixed, I'll be using Konqueror. (if you want to know why I won't use opera, substitute developers for users)
Mainly that it's an action that takes place at uncontrolled intervals and takes an unbounded amount of time to complete.
Indeed. That's why I love C++'s RAII.
Try this:
Crash.java
import java.io.*;
class Crash
{
public static void main (String [] args) throws java.io.IOException
{
while (true)
{
FileInputStream in = new FileInputStream ("Crash.java");
}
}
}
Then:
$ javac Crash.java
$ time java Crash.java
Exception in thread "main" java.io.FileNotFoundException: Crash.java (Too many open files)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
at java.io.FileInputStream.(FileInputStream.java:66)
at Crash.main(Crash.java:12)
real 0m0.259s
user 0m0.148s
sys 0m0.048s
Excuse my ignorance, but isn't there a huge difference between {removing a frame from the stack && explicit object destruction} and {garbage collection}?
Garbage collection is usually defined as automatic object destruction when there are no more pointers to it within the application. C++ doesn't do that. It can't, without taking a performance hit and taking control away from the programmer. This is not to say that garbage collection is evil (I use python regularly), only that I seriously doubt your claim to a garbage collector in gcc compiled programs. If there is one, it is probably a different definition than normal for garbage collection.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
I've found that the Linux version (running in Gnome on RedHat 9) starts consuming ungodly amounts of processor time for minor tasks--even taking 1-2 seconds to respond to buffered keypresses in a slashdot comment textarea--if it has been allowed to run for more than 24 hours. It feels like the same time every day when I have to kill -9 the process and restart it. The only exception seems to be it is able to survive a weekend of non-use. Even vs. odd days?
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Daily reboots are a Windows problem, not FF
You do realise that he's talking about restarting FF not rebooting Windows, don't you?
I've got a real clunker of a laptop, 256 MB RAM PIII, that runs FF with Flash and all that
Congratulations. I regularly see FF hit in excess of 200MB of RAM usage after a few days of normal usage. This instance has been running maybe 20 minutes (after locking up earlier) and is using 65MB already.
It's official. Most of you are morons.
Actually at least with the Windows version, I haven't noticed much of a problem with memory leaks personally. I guess that's probably because I finish whatever I'm doing and tend to close all my FF windows at least once every few hours though. Anything to fix bugs and lower resource usage is always a step in the right direction though, so I'd have to applaud this action regardless.
Smart pointers aren't constrained by having to be local.
They're also faster than garbage collection, and a lot more predictable in behavior.
Ever since, I've been suspicious of Jesus and very careful around chlorine.
It should automatically save the session, and then give you an option of reopening it the next time you launch.
No thank you - that will make it two clicks for me to start FF rather than 1, as even when it has crashed I sometimes choose not to restore the previous session.
There's no conceptual reason why the browser couldn't detect that it's not active, has been running for a few days, and hasn't been active for a few minutes (or hours) and automatically restart itself periodically.
Funnily enough, I was talking about exactly this last week with one of our sysadmins at work, about a particular problematic server. We agreed that doing that sort of thing is the absolute last resort; it is an admission of defeat, that you don't know what the cause of the problem is or how to fix it, so you're just going to restart the damn thing every so often to stop it from happening when someone's actually trying to use it.
With something like this, it's even worse - odds are every so often the damn thing would restart just as you were about to use it.
It's official. Most of you are morons.
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.
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.
You have to be kidding me. They're replacing the javascript (yuck) with FLASH (oh dear god no)?!?! Do they have an MPL licensed flash interpreter?
Give me Classic Slashdot or give me death!
This is how REAL programmers program
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
C has no concept of a finalize/destruct, hence there is NO WAY (save the above Tamarin-referenced stack-walking machismo) to reclaim memory without the programmer instructing the program to do so. The C runtime simply does not have enough "knowledge" to implement garbage collection.
..that's right, there is NO WAY your_malloc() can *possibly* know that the memory returned to hello() is no longer needed for anything. The programmer MUST call your_free() on the value returned from hello().
For example, please explain how you would implement a garbage collector to catch this:
[ecode]
char *hello(void)
{
char *s = your_malloc(12);
strcpy(s, "hello");
return s;
}
(void)hello();
[/ecode]
Now, it's certainly possible for the programmer to write something (that he calls) which helps to automate this. An excellent example is the memory pool allocation scheme used in APR (apache runtime). But, the programmer must call apr_pool_destroy() to destroy what he got from apr_pool_alloc(), or the program will (gasp) leak.
Another -- completely different -- example is the garbage collector used to implement Spidermonkey. You could (if you were feeling totally insane) use it as a garbage collector for your C code. But none of your C program's memory would be freed once you rooted an object in the gc-thing tree, unless you did something to cause it to fall out of javascript scope. Again, the C programmer must take explicit action [albeit not necessarily on an alloc-by-alloc basis] to cause memory to be freed.
Do daemons dream of electric sleep()?
No, no, and yes (sort of).
Memory protection and preemptive multitasking are entirely different animals. Their job is not to help the programmer program the application to a working state. Their job is to protect the system from a bad (or hostile) program.
Compilers do count to the degree that the writing programmer doesn't understand what the compiler is doing. One of the greatest disservices I have seen in college is the glossing over of how c++ code is translated into machine code. My first brush with what is actually going on was given to me by an upper-classman TA! The teachers themselves never have sufficiently covered the topic. The principle applies to other languages too, of course.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
I've really been annoyed by this, but I'm addicted to both adblock and mouse gestures. Would downgrading to firefox 1.x be a solution? I don't even remember if things where better then?
Really? A program written in assembly is always faster and smaller than one written in a higher-level language? I can think of a couple of algorithmic improvements that aren't readily feasible in assembly language, especially related to memory management.
how to invest, a novice's guide
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
Perhaps, but Opera does a, b and c (no idea about d, but last time I checked firefox wasn't much good on that front anyway) in a lot less memory than firefox.
I am trolling
Dare I say, It's about damn time. I've been fighting FireFox memory issues since I first started with Phoenix. Mozilla was never this bad. I rebooted at noon because Firefox was just under 800MB. I've been on the phone and/or away from my desk for 2 of the 4 hours since I rebooted. FireFox is already using 258MB. I love the Fox but this is screwed up.
I cannot help myself but comment the statement where you claim that "Simplest solutions are often the most inefficient ones". I know what you mean, and agree, if the amounts of items you are about to manipulate justify choosing the more complex algorithm. I am taking the sentence somewhat out of context, I am aware of that. And I do apologize for doing so.
:)
However, in my experience, the opposite, generally, is true. You do know the KISS principle. The most important thing - of course - is to really understand the problem area thoroughly, and choose the Right solution rather than the fanciest. If a fancier solution is not clearly justified over the simpler one, mostly erring to the side of simplicity yields code that is easier to code, understand, maintain - and on the occasion it needs to be done - refactor.
I would say, from my personal experience, that choosing a solution that fits the problem is very often the simpler rather then the more complex one. Of course, context really settles it, but simplicity is just pure gold, as we're all too bad at programming in the first place. Humans just generally suck at it big time.
That all said, I do most of my coding in C/C++, but I don't shy away from e.g. Python to use it to do a job that it fits well. However, guestimating, it's probably a bad idea to use a big mix of languages in a big project, unless the areas are very well defined. Also, the problem w/many high-level-libraries is that you become entirely clueless to what's happening under the hood, and that can lead you to do very bad choices. So being a bit picky about what libraries to use can be a good choice, indeed. And in the least getting to know what they do, a bit, too. Of course premature optimization is kind of bad, but then again it most often isn't the simplest way either.
All in all, I'm a big believer in the KISS principle, and I tend to think that there's a lot of good reason to be that, too. So choose that array over more sophisticated algorithms, if there is no doubt that you won't have many items anyways. Change it to something fancier, when there is reason to, unless you can see from the beginning that there will be loads of items to deal w/.
Sometimes I feel like people are using more complex algorithms just for the coolness factor. That simply just isn't good design.
If you're about to code the algorithm yourself, by all means - do that as an exercise - to learn ! - and then toss it, and use the array, to remove all the bugs that your own implementation of a complex algorithm would bring about unnecessarily.
The lyf so short, the craft so long to lerne
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
Read the post again. They're not replacing javascript with Flash, for heaven's sake. They're using an engine that is also used for flash, but that doesn't mean they're actually replacing javascript for flash.
That's like if someone were to release a game that used the Valve engine, and someone else were to respond "Holy cow, you're making Half-Life!"
The other difficulty with smart pointers is that (used naively), they incur a write penalty from incrementing/decrementing the counter every time a pointer is copied. Used pervasively, they can be the death of a thousand cuts performance-wise, and are quite bad for multithreaded situations too.
(On a different note, forgetting to clear an unused reference that pins an object in memory does indeed qualify a memory leak.)
DNA just wants to be free...
Well, I should say officially, "The Source" engine instead of the Valve engine.
So do I.
I fail to see how going home and restarting MY computer is going to resolve the issues on the one I'm using.
The English language has a perfectly good four-letter word which Microsoft should have used instead of "your" in that context.
THIS
You might check out the Boehm GC.
Program Intellivision!
One of the highest ignorance to knowledge ratios in Slashdot's history...
90%+ of the c/c++ guys have no clue.
99%+ of those bagging on GC have less of a clue.
They might as well be talking about girls...
Geez.
Uh, that's an Apple dialog box, mot a Microsoft one.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I can't speak about the rest of Java, but SWT, the GUI toolkit that Eclipse uses, requires you to manually dispose of GUI objects when you're done with them.
Needless to say, this can cause leaks if you're used to Java freeing things up for you. Of course, it helps that SWT disposes of any child objects when you dispose of a parent object... or at least it's supposed to.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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
Yeah, I had used opera every now and then earlier but then Ubuntu where retarded enough to stick to firefox 1.0.7 instead of 1.5 even thought it leaked memory as hell I where angry enough of it's 1.5GB of allocated memory so I switched to Opera and haven't and probably never will look back .. Opera after 8.52 rocks.
And how, pray tell, does one "cleanly" deallocate cyclic, self-referential, dynamically-typed data structures, such as the ones that naturally arise with Javascript and HTML?
With garbage collection, that's how. All possible solutions are isomorphic with garbage collection.
So the real choice is between (1) the GC-nonexpert writes their own GC to cover a subset of the data structures when they should be writing their app, or (2) to use a modern, solid, pre-written GC for the whole app.
I would also like to know how you plan to, using architecture alone, coalesce data to reduce memory fragmentation and return slack space to the system. Manually doing that to the heap is a nightmare verging on a total impossibility, whilst a good GC can do it automatically if you can afford the execution time. (And a really good GC could re-lay-out data w.r.t. cachelines to optimize performance on actual runtime data.)
Yeah, the problem is that everyone thinks he/she is a skilled programmer, and all of them still make these stupid mistakes none-the-less. We did some testing with some tools that tested for memory leaks and found that all "experienced" C++ programmers made mistakes cleaning up objects or otherwise malloced memory. The number of CPU cycles needed for garbage collection is not that huge but good programmers brains are as scarce as they were 10 years ago. Lets use those brain cycles sparingly for low level jobs, and use them for something more constructive instead.
That really depends on exactly what you mean by "surfing around", but you have to have JavaScript enabled to use google.com/ig.
Of course, once you've set it up in a more fully-featured browser, that minimal browser you're after might be enough to just read the page.
It's official. Most of you are morons.
Those are excuses 4 and 12 below.
My view of C++ is that it invokes the necessity of reflection more than any other. The people who hate C++ the most are the same people most invested in convenient solutions, for any x, where convenience == x. For almost any x, C++ is terribly inconvenient language. Which is precisely the reaons that C++ excels at solving terribly inconvenient problems, or it would have no reason to exist in the first place.
Due to the exponential nature of computing power increases, at any given time about one third of the surface area of the problems people are most highly motivated to solve are terribly inconvenient problems: the original open-ended evolution of HTML, the recent transition to Web 2.0, scaling a search engine to 500,000 compute nodes, navigating a Mars rover.
Resource management has earned a reputation as being a hard problem only because so many people are bad at it. If you can't correctly manage memory in C++, it's pretty much guaranteed you can't write a sychronization correct multithreaded application.
Most of us have learned to think in terms of preconditions, post-conditions, and invariants for coding a correct iteration that terminates. It's no different to correctly specify object lifetimes in a code base lacking automatic GC. The object comes into existence under this condition, while it exists this invariant is true, when the invariant fails, the object is disposed, and the time between the last two steps is as brief as can be practically arranged (ideally, the distance between two successive program statements).
I suspect Firefox leaks so much because the coders have descended to mechanistic thinking: to do this task we need to allocate this object, later when this mechanism is activated, if it appears correct to do so, the object is disposed. Sweet. We completely bypassed the inconvenient step of specifying a rigorous object lifetime invariant expression. Hurray! The project will ship on schedule.
By contrast, the Java programmer is spared any guilt over bypassing this difficult logical step. Only the GC doesn't entirely save you. If by a logical error, you leave a reference to an object intact that is in fact no longer needed, the GC will never free this object. With any luck, the object maintaining this unnecessary reference will get cleaned up later on, and by implication also its orphans. And there won't be much surface evidence of this missed logical step either, aside from the usual observation that the Java app. is generally consuming far more memory than you would like to believe.
One C++ project I happen to like is the monotone SCM. When you set out to write a rigorous SCM tool, you are committing yourself to a life time of high calorie lunches at the reflection buffet. At this point, C++ is the least of your problems. In fact, I always gravitate toward projects where convenience for its own sake is shuffled out the door on day one. Do you think Google built their massively parallel computational architecture by showing up every day asking themselves first of all "what is most convenient?" No, a challenge on that scale demands a renewed investment in hard thinking after every meal.
I would learn Haskell for the inconvenience it offers, but I already enjoy 90% of the inconvenience that functional programming has to offer by grappling with C++ template instantiations.
To paraphrase Einstein--for those of you who find it tedious and inconvenient to wade through a sustained meditation--your programming language should be as convenient as possible, but never more convenient that the problem your program is attempting to solve.
To update Knuth: premature convenience is the root of all evil.
Actually, the big language culprits would be those with auto-garbage collection, etc. as they tend to have lazier programmers that don't "need" to manage their own resources, and in some cases even prohibit the programmer from being able to manage their resources.
Given this comment, I'm pretty sure the only garbage collected language you've used is Java, or perhaps a community language like Python. I assure you that garbage collection is quite efficient in serious languages when compared to manual memory management (see OCaml) if you actually read the GC literature on effective algorithms and not simply assume reference counting or other naive GC scheme is clearly optimal; more importantly, automatic memory management is much safer since there are no leaks.
Heck, even Mono's C# implementation uses half the memory of the Java VM, and Mono still uses conservative GC, not accurate GC! Memory efficient GC'd languages are possible, and profiling your application in such languages to isolate and optimize resource use is entirely possible, and in the end, you have no leaks due to the automatic memory management. You can't say the latter for any C/C++ software.
C/C++ and similar languages, on the other hand, force the programmers to manage their resources.
This what I call "The Grand Misconception". C/C++ does not "force" you to manage resources at all. In fact, the complete lack of this forcing is the result of most bugs with C/C++ programs: leaks, buffer overflows, etc. The C/C++ type systems are simply not powerful enough to reason about resource lifecycles, which means you are free to manage resources, or not, or manage them improperly, at your leisure; sounds great sometimes, and yet it leaves us with software like IE, Firefox, etc., which are generally funtional, but where leaks and security holes are prevalent and likely impossible to entirely eliminate. Any resource leak is an exploitable security hole, period (but not the only source of security holes).
If a language did actually force you to manage resources, then it would produce compile-time errors when you misused a resource, ie. early deallocation, dangling pointers, etc. If you don't understand what that means, then I suggest you read up on more CS literature, specifically linear types, alias types, region types, and region-based memory management (as used in the Cyclone language). These are type systems where resources can be managed more explicitly, but which produce compile-time errors when a resource is misused in some way.
Higher Logics: where programming meets science.
> (On a different note, forgetting to clear an unused reference that pins an object in memory does indeed qualify a memory leak.)
... I tried to make the subtle difference between memory that's forgotten, but could still be freed and memory that's irrevocably lost (no pointer to it anywhere in the program, but not freed) ... but yeah ... it's a memory leak as well.
I know
Your post leaves out some crucial details.
Yes, Netscape Communicator was closed-source, and yes, its source was released in 1998. However, the released source code was so unmanagable that they rewrote the entire thing. Mozilla (renamed later to Mozilla Application Suite) was born from that. It was an interface based on Gecko, the rendering engine.
As for Firefox, it's nothing more than an interface fork from the old Mozilla Application Suite.
It's quite easy to do a C++ garbage collector, actually. I've submitted mine to boost (I am not a very competent C++ programmer, but something needs to be done for the memory problems of large C++ applications).
I'm not sure if it's Vista, or just Firefox getting better after the 2.0.0.6 branch, but I've noticed GB-sized memory consumption/freezing a lot less on Vista than with previous usage on XP. I think the problem actually is being improved somewhat, regardless of what's really fixing it.
Regardless, I find the MozFoundation's attitude toward this evasive, given the magnitude of the problem and how long it has been affecting people's machines. I simply find it irresponsible to write unnecissarily resource-gobbling applications, period. Think how much extra power machines are pulling because of this.
Do not downmod posts "overrated" simply because you disagree with them.
It depends on the application. If you have a few large objects, then manual memory management wins. If you have lots of little small objects, a generational copying collector is a much better proposition.
You should try Java 1.5 sometimes. Allocation of objects is so fast, it's practically equal to using the stack.
Certainly, and while we're at it let's not forget the basics, such as knowing how to do long division by hand.
The higher the technology, the sharper that two-edged sword.
first, there's no such standard like "Web 2.0".
:)
second, code space does not equal freestore(heap) or stack space. often, one is a tradeoff for other.
third, see my post above. i said that you have to sacrifice features.
i could also tell you about what i HAVE implemented in under 100kb of Thumb codespace, but its not possible, no way in hell, so why bother
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
One frustrating thing about this is that fixing memory leaks is relatively easy. To have any memory leak is unnecessary and a sign of a mediocre programmer.
To find a memory leak just instrument the memory allocator. See what's left when you exit the program and that's your memory leak.
There are several commercial/freeware packages that will do this or just roll your own. This will catch all memory leaks that aren't caused by memory corruption, including ones created by threads, addons and interpreted code. You can even use it with a garbage collector to see why certain blocks of memory aren't being freed by the collector. It has an overhead but not a major one and on a fast development machine it's easily usable, particularly if you're able to take advantage of a second CPU.
The firefox developers should create a beta build with instrumented memory allocation. Better yet make it part of the standard build (it's small) and enable it with a configuration option. The instrumentation could be made quite sophisticated with arena's, snapshots, tagged allocations and the like but even a basic calling PC log would be a big win.
Memory corruption is a different ballgame. For that you need to do much more sophisticated instrumentation that will catch bounds violations and unallocated pointer access. Possible, but can cause the program to run so much slower that it becomes impractical to do on a large scale. Should still be done occasionally though just to see what obvious, easily fixed violations are occurring.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
MOD PARENT UP!!
This is the most educative post in this entire article.
We are Turing O-Machines. The Oracle is out there.
And I've ran Firefox on various SUSE and openSUSE distros, while using a shit load of plugins (Adblock+, Adblock Filterset, Beagle, Dict, Fission, Image Zoom, NoScript, Resurect page, Session manager, Unplug) and browser-plugins (MPlayer, GNUClasspath's Webgcj and Gnash). I've regularly got dozens of opened tabs, of which a significant part is caried over between each sesssion. :
.DLL" plugin eats up memory, the memory is allocated for the firefox process. Once the plugin is finished, its memory stays allocated (because the allocator application - Firefox - isn't closed yet).
And I've almost never encountered any problem at all (with day long sessions). Really. This on a PIII-generation processor with less than 1GB of ram.
The only couple of time I encountered something was
- A Suse package where they forgot to disable the debug-log feature, quickly fixed with a newer package a few days later.
- Using unstable alpha Gnome package sometimes crash on opening certain dialogs. As soon as a I replaced with stable Gnome. Everything was back to normal.
Though, the last few time I tried installing the Easy Gesture plugins (a radial menu gizmo) memory usage completely crapped out. Back to normal by removing the plugin. Thus I'm actually ready to believe that memory hogs are due to some badly behaving plugins. That explains why only some people experience them : only the users with the bad combination of plug-ins have problems.
Also, note that mplayer, webgcj and gnash browser plugins, aren't actually plugins, but thin wrappers that launch player in separate process and integrate the output inside the webpage (just like the mozplugger did back then).
Other browser plugins that are dynamic libraries and thus run inside the same process as firefox. If ".so /
Gnash and MPlayer are separate process. They allocate their own memory and once they finish, the process is closed and everything allocated by it is freed.
I've observed that some flash pages make Gnash process go mad. Hopefully as it's a separate process, it's easy to kill. But means that, had it not been a separated process, it would have been Firefox that would eat 1GB virtual memory). In fact the few couple of time I've tried installing the Macromedia Flash browser plugin, I've experienced massive instabilities (FF freezing when closing tabs and such). Even now when I use the stand-alone player, very often is freezes or jumps its memory usage. Adobe Acrobat was another browser plugins that doesn't behave well (I've never attempted installing it, I've seen enough horror stories on friends' computers).
Thus most memory leaks could be blame to some plugins and very probably to badly behaving closed source browser plugins that run as dynamic libraries in the same process.
That, or there some mysterious anomaly that causes opensuse's firefox packages to behave differently as the rest of firefox installations on other machine.
Saddly that's not technically possible. At least not in a easy way. Because most plugins, both Firefox extensions and browser plugins, run in the same process as Firefox it self. All memory gets allocated by the same process : "firefox-bin".
To be able to distinguish between memory allocated by firefox' core and plugins, what is needed is complex system that uses hooks into the malloc/free procedures (just like valgrind and similar memory debugging tools) and also some kind of "context" variable that gets changed before jumping into and after returning from code in plugins, so the hooked malloc/free can guess whose is the code that allocated
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
There's no way you can make me use Azureus over uTorrent, or a browser written in Java over Opera.
We are Turing O-Machines. The Oracle is out there.
I bet that she has no firefox extension plugins (the thing that goes inside extension manager), but that she has both adobe/macromedi flash and sun java (and eventually adobe acrobat and realone player) browser plugins installed (the things that go insed about:plugins).
Those are piece of code that plug inside firefox main process too. In fact they are worse because they are dynamic libraries (.dll /
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I hope by "readily feasible", you mean "hard, but not impossible". Obviously (and necessarily) anything that can be done in a higher-level language can be done in assembly.
...towards older men. "Mozilla Firefox. The only browser with more leaks than you with that bad prostate."
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
You are fighting a losing battle. (Or perhaps I should say "loosing" battle?) People who are unable to modernize have dismissed assembly language, high-level languages (like C), OOP, etc as "hand-holding tools" that real programmers didn't need, but those things took over anyway.
If you can't code in binary/hexadecimal, you belong in a different profession. But you also belong in a different profession if you willingly chose to code in binary/hexadecimal and refuse to use new technologies that would make you more efficient.
If something will make you a more efficient programmer, it's a good thing! It's not something to be dismissed!
That doesn't mean you should always use the latest and greatest. After all, assembly still has it's place. It just means you shouldn't think of new more efficient ways of programming as being only for poor programmers.
Thank you!
I almost take back most of my post. "Almost", because, while I'm technically correct, the cases which break the Boehm (and other C) garbage collectors really have no business in 99% of C code, and can certainly be designed around if garbage collection were chosen as a memory management technique at the outset.
I actually read that page (or one like it) about 10 years ago. But I was too green back then to fully understand it, and so I promptly forgot about it.
Interestingly enough, now I know where the Macromedia guys got their ideas for the Actionscript (cum Tamarin) garbage collector. It's really quite a lot like the Boehm collector and other tweaks described in some of the linked papers. They truly have stood on the shoulders of giants.
I guess it goes to show -- no matter HOW MANY C tricks you know, there is always some guy out there the net with one that'll blow your socks off. Thanks!
Do daemons dream of electric sleep()?
I run FF on Windows at work. It's not a problem for a day or so (which is quite common for me) but after two or three days it will be using a ton. Just making sure I close all windows once in a while fixes all that.
For everything running under firefox-bin... hooking malloc is exactly what I'd suggest. If they are written in something like JavaScript it shouldn't be that hard to tag allocations. If they are written native then scan them for malloc calls and such and refuse to load. They should call ffmalloc (or whatever you want to call it) and it's (new) friends. That would make keeping track of it rather easy.
I'm not saying this is perfect. I'm not saying it's the world's cleanest idea. But it would give a good idea of what was going on. Using a separate thread for each thing would improve things, but that has tons of problems (especially synchronization, unless you run everything serially one thread chaining to the next, but that's quite hideous).
As for the "when X is doing Y" thing... that's near impossible. With the above in the developer should be able to put some sane warnings on it, but that was mostly a little "think is how I think things should behave" bit, not really something to implement. It was going to be that kind of suggestion, but it got nearly impossible fast.
I've heard the new JS/EMCA engine that they are working on should fix some of that stuff, but that is quite a ways off.
It's OK. Firefox is a great browser. I love Safari on my Mac, but on Windows I'm hooked on FF. Safari is nice, but since Apple loves to re-implement everything it isn't the fastest horse in town. IE is... well... the browser just got tabs last year. It's really hard to debug CSS type issues, and I frankly thing 7 is just plain ugly.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
There's Opera 9.23 stable and there's Opera 9.5 Beta (codename Kestrel).
Even as Opera is known to be fast and use little memory, Opera 9.5 is faster and uses even less memory, being the best browser I have ever used.
I also use Safari sometimes (to have two gmail accounts open, for example) and I'm in windows. There's no reason to use IE at all.
However, it's still a beta, YMMV, etc.
We are Turing O-Machines. The Oracle is out there.
Of course. I'm sure you could implement memory pools in assembly language, but I'm not sure that the natural and idiomatic way to write assembly code lends itself to the best representation of certain algorithms and optimizations. (It is interesting to consider that both assembly and very high level languages, at least 3GLs, both support eval natively.)
how to invest, a novice's guide
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
"Wow. I think I just scared my self."
The REALLY scary thing at Microsoft is to get to know some "Marketing" people. Hollywood's horror movies are a laugh compared to the horror of at least some of Microsoft Marketing.
I've met Microsoft Marketing people who are zombies, who don't actually contribute anything to Microsoft, but to continue to get paid they have to pretend they do. Every day they wake up and pretend to have a job. And Microsoft pretends that they are useful.
It's that sneaky insanity that is scariest.
You don't have to force quit Firefox to save your tabs. Just set it to open "My windows and tabs from last time" as the startup option. Your tabs will be automatically saved when you close Firefox. I find too many people abusing the crash recovery system just to save their tabs, when setting a simple option on the first options page will do what they want.
Hydraulic pizza oven!! Guided missile! Herring sandwich! Styrofoam! Jayne Mansfield! Aluminum siding! Borax!
Nor anyone making sweeping generalities.
This issue always comes up, and it seems the vast majority of the people in this thread are bashing Firefox/Mozilla, but they are ignoring three very crucial points.
1 - The code already has been tested with garbage collectors, Valgrind and the like. Most memory leaks hopefully have already been caught, but they are recommitting themselves to this task.
2 - Mozilla is not responsible for the poor javascript and such prevalent in various extensions written by third parties.
3 - This is the most important part, the massive memory and CPU usage is a feature, not a bug, and can quickly be disabled. Firefox 2 and 3 cache fully rendered versions of pages, so that it is "quicker" when you hit the back button. It doesn't have to rerender the page. Personally, I don't care for this feature, and so I tell Firefox to use less memory.
http://kb.mozillazine.org/Memory_Leak
Google is a powerful tool. Slashdot readers should familiarize themselves with it before crucifying Mozilla.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Define a memory leak.
To most, a memory leak is simply when a pointer to memory is lost. This is something GC can theoretically solve. But is that truely a memory leak?
I propose that that is really the symptom of a memory leak, and that a memory leak is truly maintaining memory beyond when it is needed. This is something a GC cannot solve, as you may still have a valid pointer pointing to the memory still in scope even when the memory is no longer needed.
How does this differ? Consider a single function that allocates some memory, makes use of it, and then goes on to do something else that doesn't require the memory; the pointer to the memory is in scope throughout the entire life of the function. According to the "normal" view of a memory leak, there would be no memory leak in this function unless the memory was not freed before the end of the function - or a GC would clean it up shortly after the function leaves scope. However, according to my proposed definition, even if you waited until the end of the function and then cleaned up all your memory, it would still be a memory leak as you kept the memory around longer than you needed.
Now perhaps in a normal desktop environment the difference is not a big deal. However, it would be a big deal in an embedded or OS kernel environment, or any other environment where either performance or memory utilization needed to be maximized (e.g. a program that performed tasks that utilized gobs and gobs of memory and needed all the memory it could get).
I wouldn't necessarily call it the "Grand Misconception". And if you read my other posts in this thread you would notice that my view does not adhere that as a misconception at all - rather, it takes that into account as being the mechanism by which the program is forced to do their resource management.
Honestly, OS's have to manage their resources - file systems, memory, processor time, and all kinds of stuff - and in reality, every program is in effect a small operating system dedicated to a single task, the task of what the program is trying to achieve, that is built on top of other operating systems - e.g. standing on the shoulders of giants. Programs really do need to manage their resources, which in most cases is just memory and UI resources, and sometimes involves files and devices too; often some of this can be left to the host operating system, however, anything that causes the program to fail forces the programmer to fix it - thus memory management is required for any program. GC's allow a programmer to be lazy by not doing this; languages like C and C++ - Pascal, Ada, and many others even - force programmers to manage their memory or risk crashing due to memory leaks (" normal" definition memory leaks).
Now may be you don't agree - that's fine. However, we should all strive to be better programmers, and learning how to manage our resources is one step along the way - a necessary step at that.
It is only impossible to entirely eliminate it if the lower levels do
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 point is that there is a general trend over time to use higher and higher memory abstraction, and C/C++ seems to be falling behind a bit. I don't know if Java's memory management is the ideal, but it is probably closer to what the future de-facto systems language(s) will be.
Table-ized A.I.
Actually, it's fairly well accepted that making a computer "feel" responsive is far more important to desktop users than increasing its throughput. For example, Ubuntu's desktop and server distributions have different kernel parameters targetted respectively to improve UI latency and throughput. For specifics on the web, check out Jacob Nielsen's site (he lists further references for HCI studies). The quickest way to make an application feel unusably slow is to block the UI while processing, so it is crucial that UI interaction either be very fast, or delegate its work to another thread/process.
It's perfectly fine to trade efficiency for simplicity, but UI latency is not the place to do that trade.
Holy cow did I learn something from my post that started all this controversy: C/C++ is popular with those who have a lot of mod weight on /. and they are not afraid to use it if you criticize their favorite tool.
Table-ized A.I.
(throws chair!)
/banner.jpg then /sidebar.jpg then /bottom.jpg etc - these hits seemed to be faster, perhaps it's time for something like this to be built into a browser?
In all seriousness though, I want performance from FF, feature wise the latest stable 2.0 releases with the addons I've installed (about 6 iirc) is more than enough for my _current_ needs.
I want to see this application pick up in speed, a lot.
Sure it's fast now but goddamnit people I (you?) want more - I've got 4gb of ram, I've got dual core processors, I've got fast hard disks but still the web isn't fast enough.
I'm not a developer, I'm an enthusiast, take my posts with as much salt as you like but I've found the speed of opening web pages hasn't particularly improved that much in the past 10 years.
Sure the pages are more complex, no denying it, I'm not completely dopey.
We used to open what? 50kb of html / images on dialup 10 years back, now how big is your average page, (I honestly don't know) but based on my bandwidth use, quantity of pages I hit, I think it would surely have to be under 500kb.
See the thing is, I don't find the cache use in any browser clever enough, it just doesn't seem to get hit enough at least that's what I'd theorise.
While I'm at it, the one thing I've found which increased performance massively for me was a small application called 'easy dns' - I believe it's no longer available and either way I can't install it on every machine I browse on, but it was a DNS caching tool, lets you add up to 10 DNS servers, it would chose the best ones AND cache whatever ones it had already opened.
When your browser hits
This may come across like a big whine but honestly, I think FF is fantastic, the features are rich and it works well but hell, let's keep improving, I'd love to see the web truely, amazingly quick.
While I'm on that note, perhaps some performance tips for FF would be in order, anyone got any?
Unfortunately, as talented as the team is, there are limits to the architecture.
There is no such thing as an accurate C++ garbage collector and anyone that says they can write a huge app in C++ and not have a memory leak is just an arrogant ass. Once you mix in Javascript forget it altogether.
Interestingly, this is not only due to the talent of the team in writing C++, but due to the desire to port this thing across platforms.
As slow as it may be compared to C++, Java itself would be a sensible solution, given that the ugly hacks would at least
have some portability and an accurate garbage collector to rely on.
Its called diminishing returns, and every line of code added to Firefox diminishes the returns even more.
Has anyone remarked that these CPU and memory issues have been going on since Netscape?
Firefox was not always so rife this problem. Lately though it does seem to be getting worse.
What C++ moderator gave that a 5?
There is not a single object in a single OO program that can possibly have the correct responsibility for freeing its memory
EXCEPT a garbage collector.
Its nonsense like this which is why any sizable C++ production app will take years to work out its "memory leaks".
And thats the best C++ coders around writing those apps.
So you explain if you want to go off on such a tangent, exactly how an OBJECT or a CLASS knows when all its consumer objects are done with it?
Reference counting at the app level? Almost all C++ apps have some feature like this. And they ALL have memory leaks.
You are up a computer science creek with no paddle my friend. You havent addressed long lived and short lived objects,
Objects exposed by API which have no "open" and "cleanup" methods, transactions, statics, you are just a fool.
And any app you wrote or anyone else ever did in C++ has memory leaks.
Period end of story. Moderators, Please stop ranking C++ purists as insightful when they are spouting on about technological impossibilities.
Large C++ apps ALL have memory leaks. Its a mathematical certainty not a statistic regarding bad coding practices. And there is no solution but an accurate garbage collector which is a technological wonder in and of itself. Java has one.
The only difference between Java programmers and C++ programmers in this issue is that java programmers have THE GOOD SENSE to know they cant and shouldnt bother to write garbage collection routines when they write an app. Especially since computer science has only come up with a few ways to do it by smarter people than them with alot more time on their hands.
233 millibytes isn't really that much of your computer's resources, when you get right down to it. Add in the virtual memory and it's only 0.97 bytes.
I may make you feel, but I can't make you think.
In 1.5, leftclick and hold brings up the contextual menu.
In 2.0 and up, you HAVE to hold down a key on the keyboard and right click.
And there is NO preferences option to change it back.
What dipwad thought THAT was a good idea?
Fix the broken usabilty/human interface bits, as well as the memory leaks and then maybe you'll have a decent browser once again.
In the meantime, I'm sticking with 1.5. The FireFox browser that's not broken.
Guaranteed! This comment 100% Anthrax free!
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.
I'm aware of Tamarin but it won't help them, since interpretation speed isn't their bottleneck.
Firefox responsiveness feels bad because the entire application is rolled up into a single thread, where the UI keeps stalling waiting for something not directly related to happen in the backend.
Unless this is fixed, Firefox will keep stalling. It'll stall "faster" but it'll stall for the same time. I leave it to you if this helps much.
Conservative GC scares the hell out of me too, but it *seems* to work well enough in practice. Still makes me nervous. The Boehm GC leaks like crazy, but something that's mostly-precise, like SBCL's garbage collector, seems to do okay.
Oh, and the linked article seems wrong; SBCL's GC is both conservative and generational.
Just to add to this, in many cases, smart pointers don't just help, but are simply essential in well-behaved C++. If you have more than one new in a constructor without the results being assigned to smart pointers, you have a potential memory leak - if either throws, your destructor with deletes in it is not going to be called, since the object dit not finish constructing!
There's really very little excuse for writing plain delete anywhere in your C++ code these days. It almost certainly won't make things any faster, and is very likely to introduce subtle but real opportunities for memory leaks (see my other post detailing one particular issue with constructors, for example).
Given that the C++ committee is seriously considering garbage collection for inclusion in C++09, and Bjarne Stroustroup personally considers it one of the most important improvements, I'd say that people claiming that GC is not the "C++ way" are wrong.
"If you can't code without hand-holding tools like automatic garbage collection, perhaps you belong in a different profession!"
Sure. But if you fail to understand and use these tools were apropriate you belong in a different profession as well.
I use Opera on Windows. The UI is pretty damn customisable, and within minutes you can have it doing exactly what you want.
Skins can be downloaded and installed in seconds. And I mean seconds. The main toolbar, the address bar, status bar, etc are all customisable, and you can add, remove and tinker with them and their elements very easily.
Getting a UI that you're not only happy with but that also feels more intuitive to you and that makes you more productive in the long run is very quick and easy to do.
'Out of the box', Opera's default UI is very usable. With a few simple clicks via the installation wizards it can be made more so. And, of course, with a few more minutes spent adjusting things it can be made to feel very personalised.
To be honest, I find it a rather hypocritical (and hilarious) complaint for a Firefox user to make, given that the typical Firefox user will do far more of the same (install, skin, tweak, customise), and on top of that will spend far more of time downloading, installing and customising add-ons, many of which purely play catch-up to core Opera features.
The idea that Opera 'out of the box' is "excessively duanting" compared to Firefox 'out of the box' for casual users is just the funniest thing I've heard in a long time.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
You could use AT to schedule a "shutdown -f -r -t 5" once a day, at (e.g.) 01:00 - assuming you're auto-logging in to a session, and your software is set to autostart afterwards.
F_T
Browser caches suck, you're right.
I set up a cacheing proxy (squid) and it's the single biggest improvment to my browsing experience ever. I give it around 6 gigabytes (powers of 2) to play with, in a combination of the file stores and the experimental newer object store (for the bigger crap), and tweaked the expiration times to meet my single-user needs (keep the data for weeks folks). Pages just come up kablam.
The huge number of incidental stupid little bitmaps on sites are all a local socket away.
What's interesting is to look at the performance characterstics of copying 300kb - a few megs of graphics over a local socket vs mmapping it in or whatever. It's a nontrivial additional amount of time to do all those memcpys and context switches. But it beats the HELL out of any browser cache. I don't understand why the browser people can't, in the worst case, just use the guts of a decent http caching proxy. Some of them are open source guys!
-josh
While I'm not especially a fan of garbage collection, it seems to me what you're ranting about is reference counting, not all garbage collection. Tracing garbage collectors, like Java's, have none of those problems.
Admittedly, I don't stress it on this 'ere XP box as much as I do on my G5 at home, where my norm is probably four or five windows holding anything up to 50 or 60 tabs between them, and I leave it running all the time. (Or at least, as long as I can until it gets unbearable and I have to take my life in my hands and hope that it doesn't forget all my tabs when I restart!)
What's most annoying with the Mac version, though, is the lack of responsiveness. I don't mind it taking ten seconds or so to open a page; well, I do, but it'd be very bearable if it didn't also completely freeze the GUI for the first half of that, and then react very slowly and jerkily for the rest.
I can't say I like XP, but there at least Firefox is relatively responsive when it's busy. Having the Mac OS X version beachball whenever it does anything is most annoying.
Oh, and while we're talking of Mac Firefox woes, does anyone else find that it won't show Flash unless it doesn't fit on screen? If I scroll down so that the the Flash area goes off the top, even just by a pixel, then it appears fine; but if the whole of the Flash area is visible then it won't redraw properly; often it's completely blank. Could this be a plugin issue, or am I doing something wrong?
Ceterum censeo subscriptionem esse delendam.
I'm using the latest build of Firefox 3 (gran paradiso) on Linux right now and it doesn't crash or gets slow anymore like Firefox 2 did when I had more than 20+ tabs open, this version of Gecko also passes the Acid2 test, Firefox 3 will be a great release. Thanks Mozilla developers for all this ;)
I'm just curious what exactly everyone is doing (on Windows I understand Firefox has different problems on Mac) that causes Firefox's memory usage to be a problem on a modern box.
I have a gig of RAM, 256 of which goes right to a VMware instance, run Outlook all day long, usually have photoshop open, and work with Firefox all day long. Multiple tabs, plenty of fun little extensions, Flash, the whole package.
So what clues you into Firefox's memory usage? Does your system start running slowly? Or are you opening Task Manager seeing Firefox is using 200megs and getting angry?
Maybe I have better luck because I shutdown nightly.
-- taking over the world, we are.
So when a company or group of coders say they can't fix their memory bugs, I say bull----. When they say that the parent company doesn't pay for fixed code, that I believe.
So if ten years after a small team of four had a bug and memory-leak free code stack, the fact a browser still leaks like a stuck pig after the hundreds of thousands of hours of code that went into Firefox, then it's obvious where the fault lies.
Especially because if they prioritized that fix, coders like me might actually be interested in contributing again.
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
"Sometimes "works for me!" is a valid response..."
I definitely agree that "works for me" can be a valid response. In the case of the Firefox CPU hogging and memory gobbling bug, however, Mozilla developers are routinely saying "works for me" without duplicating the conditions under which Firefox fails, or even reading the reports carefully.
Why? I don't know, but I have theories. The politics inside Mozilla Foundation, which now takes in $50 million each year because of making Google the default search engine, seems to somehow favor those who work on the easier bugs to fix. This makes sense, since the chief of Mozilla is a woman with no knowledge or interest in technical things. (See my earlier comment for links.) There can be no effective supervision because the top executive cannot understand even the simplest social issues surrounding Mozilla Foundation software development.
There is a huge variation in Firefox use between users. Most users apparently finish with one issue before they go to the next. Some, however, are extremely heavy users. For example, a computer parts buyer for a corporation that builds computers may need to keep an issue open until he or she gets from answers somewhere else. It is those users, who keep many windows and tabs open for days, with numerous hibernations, who experience the worst memory gobbling and CPU hogging.
There are other contributing factors. People who work especially fast seem to have more problems. Those who have more than one Mozilla program open, for example Thunderbird and Firefox, sometimes see that the CPU hogging bug is shared between Mozilla programs, so that, as many windows and tabs are open in Firefox, Thunderbird begins hogging the CPU! And that tends to corrupt Windows XP; although Windows XP will still operate somewhat after all Mozilla programs are closed, some OS operations will be quirky or inoperative. The only way I've found to return to normal Windows XP operation is to re-start the computer.
As I type this, Firefox is using up to 29 percent of the CPU, sometimes peaking at over 60, with no Firefox activity, since I am typing into an editor. So, later I face the need to close all my Firefox windows and tabs, even though I am not finished with some issues.
I propose that that is really the symptom of a memory leak, and that a memory leak is truly maintaining memory beyond when it is needed. This is something a GC cannot solve, as you may still have a valid pointer pointing to the memory still in scope even when the memory is no longer needed.
How does this differ? Consider a single function that allocates some memory, makes use of it, and then goes on to do something else that doesn't require the memory; the pointer to the memory is in scope throughout the entire life of the function.
Let's define two terms to further clarify: automatic memory management (AMM) and manual memory management (MMM). Given a particular AMM, your statement might be true. However, it is not true for all AMM techniques. It is also not true of all MMM techniques, but this property depends on the cleverness of the end-programmer, instead of the compiler implementor. I think you'll agree that the compiler implementor is likely to be the better programmer.
Honestly, OS's have to manage their resources - file systems, memory, processor time, and all kinds of stuff - and in reality, every program is in effect a small operating system dedicated to a single task, the task of what the program is trying to achieve, that is built on top of other operating systems - e.g. standing on the shoulders of giants.
The set of all programs that are non-terminating (like an OS) is a subset of the set of all programs. So no, not every program is like an OS. It also does not follow that a program must manage every byte of memory, because OS's deal with resources at a coarser granularity (pages mostly).
Programs really do need to manage their resources
I do not contest the statement that resources must be properly accounted for in any system (as improper accounting is the source of many security vulnerabilities), but I do contest the statement that this accounting must be manual.
GC's allow a programmer to be lazy by not doing this; languages like C and C++ - Pascal, Ada, and many others even - force programmers to manage their memory or risk crashing due to memory leaks (" normal" definition memory leaks).
It's not a matter of laziness, it's a matter of hard design and error-prone usage. Introducing MMM has a ripple effect on an entire system, where its structure becomes exponentially more complicated in order to properly manage resources crossing interface boundaries. You can see this for yourself by contrasting the simplicity of libraries written in functional languages against those written in C/C++.
It is only impossible to entirely eliminate it if the lower levels don't manage their memory properly either.
This implies a stack-based memory hierarchy, in which case automatic region-inference could allocate and deallocate this memory for you even more efficiently than you yourself could. That's a solved problem. Problem is, resource lifecycles are often not stack-based; fortunately, newer region inference techniques are getting good at tackling these issues as well, and I predict that within 5 years we'll have an acceptable automatic region inference technique that will outperform MMM.
however, my code managed its memory properly and that was the only memory issue in the entire program. If Microsoft did their job, then they would have managed their memory and the memory leak would not be there at all.
Or, in order to close that 4 byte leak, MS would have had to alter the API in such a way that would force YOUR program to leak, or force you to contort your program and stand on your head in order to ensure leak-freedom. Fact is, we should leave the problems that are amenable to automation to the computers, and those that are not amenable to automation to the programmers. Memory management is an example of the former, and while there are currently domains where the automated solutions are not yet good enough, that gap is almost closed.
I will grant you that security hol
Higher Logics: where programming meets science.
In some cases using a garbage collecting language can be cheaper than several months of testing.
Installed the Bubblemon yet?
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
No professional computer programmer should have to worry about garbage collection. This can be automated, which means it should. Not doing so means that sooner or later, you'll end up with memory leaks.
You should understand what it's about, but that doesn't mean you have to do it all by hand. Programming without some smart garbage collection system is like flying an aeroplane and refusing to use the autopilot. It's asking for trouble.
But memory management should be transparent, and not interfere with your application code at all. And as far as I can see, that means garbage collection. Reference counting is leaky, explicitly allocating and deallocating infringes on application code.
Even the OS eventually terminates. I'd still put forth my paradigm works.
Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources. Even if that is simply telling the GC that an item is no longer needed so the GC doesn't have to waste as much time with determining that the item can be freed for other uses.
I still propose that no matter how complete the AMM may be, you still need a hybrid AMM/MMM such that the programmer can tell the AMM when something is no longer needed. The AMM may go further and help absolve conflicts between multi-threads, and such - and that is fine. However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.
No, it doesn't imply a stack-based hierarchy - but a mix of stack and heap which is what most programming languages have. Heap allocations are really what needs to be tracked, and there should be a way for a free() function to determine if a pointer is pointing to something on the stack or the heap. Currently, this is not very doable.
We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness. We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.
Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscurity. It also provides a fall sense of security. It may help to minimize such risk, but it does not absolve such risk - so please, stop fooling yourself.
Finally, when properly employed - C and C++ can be just as well secured as
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
There is no substitute for testing, and only dumb program managers cut themselves short on testing. And - FYI - GC makes debugging memory issues a lot harder as you have an inconsistently timed mechanism claiming memory from you. However good the GC may be - the timing differences it can cause can make a huge difference in being able to resolve something easily or not - in fact, whenever you have something that causes timing differences, the difficulty of debugging is magnitudes higher. So, even with a GC you will need to be doing months of testing.
FYI - Open Source Software can get by with shorter testing periods because the testing is spread out among thousands of people. Where as a proprietary firm, like Microsoft - with notably takes a couple months to release a patch due to testing, cannot as they have to do their all of the testing themselves.
Bad software gets out for several reasons - (1) developers don't do the engineering they should have, and (2) management crunches the schedule and doesn't let the developers do the engineering they should have or the testing that should have been done. Obviously, managers do need to manage the time line of a project, and projects need to get out. But you can't short change yourself either. I'd much rather a manager scale back a project to meet the time line than short change the engineering and testing; of course, you can't scale back too much either so this is really where the trade offs come and must be managed between the management and the developers. (Developers need to show the financial and business reasons to management for why to keep something, and should design/plan around being able to expand new features - or delayed features - in in order to help management make the deadlines. It's a two way street.)
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
I had a look at the FF code and I got the impression that it would be a full-time hobby.
Nothing that goes on in a program is completely transparent, no matter how much people would like to claim it is. Garbage collection has its place. It also has its own set of faults and problems- and it's also not perfect, and it can be a crutch. You can, in a practical sense, leak memory just as easily in a garbage collected system as you can in any other.
Explicit control, reference counting, garbage collection- the important thing with all of them is that you have to understand your memory management model and how it interacts with your application. If you don't, you'll have problems with all three. There is no panacea.
The ringing of the division bell has begun... -PF
Even the OS eventually terminates. I'd still put forth my paradigm works.
An OS, as mathematical function, is a recursive, non-terminating program. It MAY terminate, but it need not.
Accounting is a part of management. However, management goes further in that it assumes responsibility for allocating and de-allocating resources.
Accounting is not done in any mainstream language in any usable manner. Regardless, I've been arguing the lifecycle of objects is better managed automatically than manually, and you have been arguing that, at least sometimes but likely often, lifecycle needs to be managed manually. The majority of security bugs found today would have been avoided if the software had been written in a memory-safe language, and many memory leaks would not exist given AMM. We can argue the performance tradeoffs of memory safety and AMM (empirical evidence suggest exec overheads around 15-20% and memory overheads around 50-100%), but that they both eliminate large classes of bugs, including security vulnerabilities, is an indisputable fact.
However, the programmer still should have a way to tell it when it is done - perhaps as the programmer I want to release memory half way through a function instead of waiting for the pointer to go out of scope when the function exits.
But why? If the region-inferencer (for example), determines that the lifecycle of a chunk of memory isn't used halfway through the function, then it will do it for you. If it's not smart enough, then you can refactor your function into two functions to ensure that regions are scoped differently. As a bonus, this results in a better design.
Further, your approach can have a pathological effect on performance due to micromanagement. Why incur all the overhead of alloc/free'ing individual objects when you can alloc/free entire regions of objects at once. This is incredibly efficient, and further, leads to more efficient bump-pointer allocation techniques. Are you aware of the searching and fragmentation overhead induced by libc's malloc/free? This has been extensively studied.
We know how to write software that is only as secure as the attack vectors that we are aware of. Claiming otherwise is foolishness.
I can legitimately claim otherwise because software written to a POLA standard is maximally defensive, and so any remaining security holes are either
a) an implementation bug which does not follow the specification, or
b) inherent to the problem being solved and thus, fundamentally unsolvable without changing the problem specification.
Stronger static types systems help reduce a) (and C/C++ have very weak type systems), and b) is essentially unsolvable without manual intervention.
We can mitigate how software is affected by unknown attack vectors through Defensive Programming methodology, but even that can only truly protect against known vectors.
Like most generalities, your statement is both true and false. It is false in the sense that a POLA design is already maximally defensive, and so the security properties can't be made any stronger without changing the entire specification.
It's true because of the human factor in any system, and what you'll quickly find is that the majority of the security research by the capability security community are human-computer interaction attacks, ie. phishing, spoofing, etc. This is because automated attack vectors are no longer viable in POLA systems. I suggest you read the security audit of the DarpaBrowser built on the capability-secure language E for a taste.
The "Defensive Programming Methodology" is actually a degenerate, specialized case of capability security.
Additionally, reliance on a "memory-safe" language does not absolve you from buffer overflow attacks. Such reliance is foolishness - and is no better than security through obscur
Higher Logics: where programming meets science.
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.
Back in my Clipper days, I used indexed DBF files (tables) to store complex structures. They automatically cache to disk and were relatively fast. True, if you forget to delete the files when the program finished, it would take up disk space. However, it would just clean out any work tables upon the next start-up rather than add to them. Because most of the "model" was in cached tabels instead of RAM pointer structures, memory use was kept fairly small and predictable.
I don't know if this approach would work well for building a browser, but for biz apps it worked well. And it may make multiple run-time instances tricky, but I found that multiple instances tended to confuse users anyhow.
This approach is not for every application, but it provides an alternative way to deal with complex data structures. If tables allowed open-ended column sizes (which Clipper sort of supported but not efficiently), it in theory could be used to write browsers etc.
Table-ized A.I.
Garbage collectors are imperfect and consume resources; there are times when it's better to avoid them. Just as there are times, few and far between, but they do exist, where writing it in assembly is the right thing to do. Certainly writing the whole of a web browser in a language without garbage collection is an exercise in stupidity - things like the bookmark manager don't need performance (except possibly in the actual drawing, but they're using a library for that, or should be), but I would find it entirely plausible that the core of the rendering engine is best done in C.
I am trolling
A skilled craftsman does not blame the tools.
No, a skilled craftsman blames the project manager.
(and then skips on off to the pub)
I will soon try the iFox Smooth theme with the Windows version of Firefox.
If the program is adequatly designed, memory management is NOT a big development time consumer. Most of it is a matter of making sure you create constructors and destructors together so they stay in sync. All pointers should be explicitly set to NULL when they're not in use. Furthermore, unless you do analysis PROVING that a pointer CANNOT have been used, it should be checked for non-NULL, freed, then set to NULL. If that causes a crash, someone screwed up but at least you tend to find the problem rather than silently leaking memory.
If reference counting is in use at all, a debugging option should exist that overwrites all freed objects with poison just to make certain that some later access WILL be a crash bug.
Personally,I think C++ is exactly in an ANTI-sweet spot. High enough level to sweep object management under the rug (with automatic constructors no less) and allow polymorphism through casting but not high enough to have built-in duck typing or an intrinsic class membership.
By that, I mean if I set void *a to an object, I cannot simply delete a. Even worse, if a is a pointer to a base class and I delete a, I will delete the base class and silently leak any extra allocations done by the derived class's constructor. In Python (for example), where a=some object, if I delete a, it does the right thing no matter what sort of object a is. It's a mess.
C++ was an interesting experiment that started as an advanced C preprocessor. That beginning explains a lot about it's limitations as an OO language.
Sure, that's not always the case, and when it does fail you have understand memory management. But it's a lot easier to focus on the failures than worrying about allocation all the time.
If you can't separate your ego from your engineering, perhaps you belong in a different profession! Preferably one where I will never have to endure your masochistic BS.
Slashdot. It's Not For Common Sense
Wow. HTF did this get mod points?? Guys says straight up he's talking out of his ass, and it gets Insightful??
1) Mac user. WTF was that tacked on comment at the end for? reality check : Mac users know what's up, which is why they use Macs. I know perfectly well what happens when I close a window.
2) And news for you, when you close a window on any platform, it releases the object resources held by that part of the application, whether or not you quit the application. And on Windows, quitting IE by closing a window also doesn't take IE out of memory, Windows caches it to make IE's startup look fast.
3) It's as valid to say that many people don't realize that if they push the power button on the computer, it doesn't actually turn it off. On many laptops, this invokes Standby or Hibernate, which doesn't clean anything up in memory.
4) My wife works in a bank. Nobody, and I mean nobody, turns off a computer. They log out, and there the computer sits, running Windows. So your "general users" are apparently "general users who turn their computers off at the end of the day"; who, I agree, most likely turn their computer off at the end of the day.
So on-topic, I do work in the tech industry, usually have my OS X laptop at around two weeks of uptime, and happily run Firefox 2 with a NoScript and AdBlock for days on end with no crashes. It does leak, and when I decide the system needs the memory I restart, which is the work of all of maybe 15 seconds.
Yeah, I heard that garbage collection lead to the total failure of a few businesses that were otherwise likely to succeed: like Amazon, Facebook, Wikipedia and EBay. Google employs the inventor of Python and Apple added garbage collection to Objective C, so I guess those two companies are headed for the scrap heap as well. Is the usage pattern of these apps the same as Firefox's? No. But I just thought that your imagination needed a little bit of prodding since you couldn't conceive of an application in which multiple inheritance is an appropriate tool. According to you it shouldn't have been invented at all. By the way: used properly, multiple inheritance is also a nice tool!
Yes you can ALWAYS collect the trash when you know exactly how things are consumed and you have ALOT of time on your hands.
Thats called application or API specific garbage collection. The reason it doesnt work
is that any decent OO program will not be concerned with tracking client usage
because object lifetime is largely out of the scope of OO programming...in its ideal state.
So for A PARTICULAR application sure you can CLEAN UP the memory leaks.
But once you use those objects again in a different context, the leaks will be different,
so you will have to write DIFFERENT application specific garbage collection.
Thats why you are better off not doing it at all. In java for example, do you know what the biggest resource issues are?
NATIVE CODE, database connections and the like.
Of course they can be cleaned up. But its native code forcing all that to happen because native code must concern itself
with all these irrelevant things. Having an Object called a garbage collector that deals with it is the most OO thing
you could think of.
Anything that doesnt use one is simply not OO. As evidence of what Im saying, point to any new or recent languages
that DO NOT have some form of garbage collector. malloc and free are history man.
Considering how non-deterministic an ordinary system is anyway (due to swapping, system load, different CPUs characteristics etc) I don't really see how having a garbage collector would make thread races any harder to track down than before though. Do you have any actual real-life anecdotes or something to back this up?
Installed the Bubblemon yet?
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
I love GC, not because I don't have to manage the memory, but because I don't have to DEBUG memory overwrites.
I can't tell you how many hours (days, weeks) I have spent debugging a multi-threaded program only to find I was off by one somewhere.
THAT is where the savings is.
Oh yeah, developers should first create a decent design with memory usage in mind.
Sloppy developers will be sloppy in about all aspects of programming...not just memory usage, so one less thing for them to mess up is likely a good thing.
Love to Code,
Randy.
I think Carl Sagon said it best, "Take Baby Steps." At first look, FF code looks like a challange. But after awhile, one can begin to see the inner workings, and then begin to understand. I do not believe that anyone that worked on FF will be invited to go to Stockholm to collect a prize. And when one reads the personal comments of minor contributions to FF, one begins to get the concept that there just might be a solution that an "Average Joe" can submit. I applaud all the people who have made open source solutions.
"We Can Be Heros" - David Bowie
I'm advocating using languages designed for garbage collection (and that prevents the user from dealing with pointers directly).
As for timing issues, the GC will cause pauses at random times, but so will the OS' process scheduling and interrupt handling. Are you saying that GC incurred timing issues are somehow more problematic than OS incurred timing issues?
Installed the Bubblemon yet?
Also, while the article may be referring to C/C++, it would certainly extend beyond simply C/C++.
I've had this conversation before and had someone raise up that there are a number of issues - I thought it was on
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Try this:
#include <cstdio>
using std:cout; int main() { int *i; { i = NULL; cout
OMG it crashes ! C++ is shit ! I can make it crash when I purposefully create a program to do so !
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Would have modded you up if I could :-)
:-)
:-)
I did not attend the conference in question. My only trip to the US was to Denver this summer, where I attended the MS WPC.
If you have a name or two I can do a LinkedIn search?
I'll throw you a mail with the same answer
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
But what I wrote is not purposefully breaking the system, it's just forgetting to release a resource. That was the point I was trying to give an example of. Java falsely claims that you don't have to worry about releasing resources any more because the garbage collector will get it in the end. That claim only holds for resources such as memory, that are so plentiful that you don't need to immediately return them to the system. The Java example I gave is clean, it compiles, the error would more than likely be missed by most peer reviews. Even if I had closed the inputstream just before it went out of scope, an exception (or a badly placed return or continue) would bring us out of the scope before the Close() function was called. RAII gaurantees that resources are cleaned up no matter how you exit the scope.
The reason the garbage collector works for memory is that the failure to allocate sufficient memory is what triggers garbage collector, rather than any abundance of memory.
That particular problem can be solved easily with the try {} finally {} construct. FileInputStream file = null; try { file = new FileInputStream("crash.java "); } finally { if (file != null) file.close();}
But yes, this is a problem. I'm not sure there is a clean solution for it, however.
Well, the finally block will be executed no matter how the try block is exited, so such things can be arranged; however, it is a needless hassle to set up and certainly something a novice programmer - or even a senior one - could easily forget. I'm not sure there is a good solution, thought; even RAII is not applicable for every use (specifically, it can't be used for files which need to be kept open, like database files).
A bandaid might be to trigger garbage collection when the system runs out of file descriptors (since garbage-collecting an object representing an open file causes the underlaying file to be closed in Java), but that is not a general solution.
Of course, the ultimate reason for all of these troubles is that most current operating systems were written in C or C++, making them the "native" languages of the system. Writing the entire system from the kernel up with an object-oriented, type-safe, bounds-checked language would solve the whole problem. After all, a file descriptor is simply an integer, used as a token to identify an open file, which in turn is a kernel data structure; the number of open files is not inherently limited by anything but memory, so making the entire system a single garbage-collected entity would mean that any "open file" data structures no longer referenced by anyone would be cleaned up with the rest of the rubbish. After all, the only reason a file needs to be specifically closed in current systems is that the system has no way of otherwise knowing you won't be using it anymore (and because most runtime libraries, including C ones, buffer writes to files due to the high overhead of system calls).
As an added benefit, given the above constraints on memory and resource access, there would be no need to run the user code in a separate processor ring as the kernel; in fact there would be no need to run anything in a separate virtual memory context. This could potentially mean a huge recuction in the cost of system calls, interprocess communication, and context switches. It would also make Hurd-like microkernel architechtures a lot more viable.
C and Unix were born together, and the former still pretty much defines the latter (and all the imitators); maybe it is time to start building the next generation of operating systems, based on new object-oriented bounds-checked garbage-collected programming languages. Or perhaps even LispOS :).
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.