Firefox Memory Leak is a Feature 602
SenseOfHumor writes "The Firefox memory leak is not a bug. It's a feature! The 'feature' is how the pages are cached in a tabbed environment." From the article: "To improve performance when navigating (studies show that 39% of all page navigations are renavigations to pages visited less than 10 pages ago, usually using the back button), Firefox 1.5 implements a Back-Forward cache that retains the rendered document for the last five session history entries for each tab. This is a lot of data. If you have a lot of tabs, Firefox's memory usage can climb dramatically. It's a trade-off. What you get out of it is faster performance as you navigate the web."
Christ is it a waste (Score:1, Interesting)
I still like it as a browser, though.
My pet peeve! (Score:2, Interesting)
So why is it that when I open a new tab I have to manually cut/paste the same address in it. For example, replying to an article on
-Rick
Re:My pet peeve! (Score:3, Interesting)
releasing memory (Score:5, Interesting)
The heap, where dynamic allocations occur, is only allowed to grow or to be truncated. An application cannot release memory in the middle of the heap without also releasing the memory at the end of the heap.
So let's say Firefox makes 10 one-page allocations, and frees the first 9. The memory layout might look something like:
XXXXXXXXXU (X- unused, U- used)
Those 9 pages worth of memory aren't being used, but it's impossible to release them back to the OS.
Thankfully, there is some good news: when Firefox needs to allocate more memory, it can and will just reuse those 9 unused pages instead of allocating more memory from the OS and growing the heap.
The best solution to this problem is to use a compacting garbage collector. Which is something that Java and C# and other higher-level langauges can easily make use of (and many do use them), but which C and C++ can't really make use of given the complete lack of compiler support. That's one reason why a Java or C# app can actually out-perform a similar C/C++ app, especially with a good native-code compiler and an library implementation with a modern GC.
Don't bug me (Score:5, Interesting)
What is being described here sounds much more like a cache of recent pages, which in my opinion is perfectly sane for a browser. Sure, maybe the cache is a bit overzealous, but even if that's the case, just disable it - worse case scenario, you edit the source. But otherwise, this is definitely a feature - I can promise you it's much more programming effort to save old pages for a quick redraw than to free the old page and replace it with the new.
So I guess the discussion here is, "is it right for firefox to use so much memory?" My answer is yes. It is not a memory leak, it seems like a very valid design decision. But if you disagree, old versions of firefox still work great (I still haven't upgraded myself).
Re:So I'll be the first to say it.... (Score:3, Interesting)
This is proof positive, I think, that OSS != the best option in all scenarios. Opera consistently beats FF out on features, security, and speed... and it does it without having to download "extensions".
Re:releasing memory (Score:3, Interesting)
mmap() can do this, but on many systems [s]brk() cannot. brk() is also alot faster than mmap().
This is really moot on most systems; don't do a lot of little allocations that you're going to keep around for a while and DO use pooled allocators that can use mmap(). It requires planning, but it really does pay off for applications that need an awful lot of memory in stages.
This is (by the way), why many C compilers are implemented in "stages", so that they don't have to worry about crap like this. Allocate as needed, and the next stage exec() will automatically compact and garbage collect any pages used in the previous stage that aren't needed here (that weren't passed to the next process using mmap or pipes).
Re:A limitation of the C library (Score:2, Interesting)
memory is released upon calling free()
Too many C libraries' implementation of free() release memory back to the application, not to the operating system.
two words: "totally" "wrong" (Score:2, Interesting)
Re:Total cached page limit. (Score:3, Interesting)
I browse with a lot of tabs in FireFox, and with FireFox 1.5 the performance when a lot of those tabs are loading has been beyond horrible. Like several seconds just to switch tabs, and then actually trying to scroll...
If you are feeling generous, perhaps you also know how to shutoff the new tab thumbnail "feature" when you've got images. 16x16 thumbnails of 4000x4000 images are nothing but a waste of CPU time and a visual distraction.
Re:Firefox is the most unstable program in common (Score:3, Interesting)
seriously, the only thing i could think of is that if firefox ran out of ram and had to start using the pagefile, that would eat up tonnes of CPU. This would also effect other programs on the system. Are you sure you have enough ram in the machine? I assume you can replicate this bug on more than one machine right?
Ive had some sites crash firefox repeatidly but i cant think of any examples off hand.
Re:sounds good to me (Score:3, Interesting)
You've totally missed the point. People aren't bitching because the back and forward buttons are faster. They're bitching because the memory used for the fast back/forward is never released. Because Opera implements the same feature even faster and doesn't use >85% of physical memory after 20 minutes. Because a web browser should not use >1 GB of RAM because it's left open over night.
Re:Why does Opera work well, and not Firefox? (Score:3, Interesting)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
And I can not duplicate any of those issues.
When clicking forwadr and back buttons quickyl, I manged to spike at 60% for a brief moment.
I have ahd it running all day.
I do not use the feature that lets some of it stay resident so opening it up is quicker, so maybe the problem is there.
Any clues on ther things I can try to duplicate this issue?
to address this specific issue, more memory does not equal memory leak. Yes, the cahching mechanizim may be too agressive, but if it ahs been designed that way, then it is, in fact, a feature.
Some other poster suggest setting changes that seem to take care of this issue.
Re:Total cached page limit. (Score:3, Interesting)
Simple fix (Score:2, Interesting)
Re:So I'll be the first to say it.... (Score:4, Interesting)
Well, you just picked up the worst reason - opera is great when it comes to performance, but firefox + extensions consistently beat opera and IE when it comes to features. I can have the features I want, there're way more extensions that features than opera has, and if I don't want them, I don't need to keep the extra UI involved in those features.
Re:Don't bug me (Score:1, Interesting)
Firefox 1.5 was regularly using 1GB+ of memory under normal browsing with _one_ tab. I have 1gb of actual memory so it was spilling over into the page file on the hd and affecting all other programs. Personally I've never seen such an obscene memory leak on non beta software, even from IE. However, now that I'm using 1.5.0.1, I haven't seen it go over 200mb of memory usage. Clearly there was a major problem somewhere that was fixed.
Cluecheck! (Score:3, Interesting)
Firefox: 54.15M (Real) 190.07M (VM) ; 2.1% idle
Opera : 59.36M (Real) 239.66M (VM) ; 0.4% idle
Assessment: This Firefox outperforms both Opera and Safari in memory usage, and is faster than Opera on challenging pages. However it has the least favorable idling habits, starting at 2% here and would climb to 4% after several days of intensive use. FF 1.5.0.1 memory use would climb to about 100M for the same pages over the same period, indicating the cache grows somewhat but not wildly the way FF 1.5 did.
The test of also rather unfair, as I have 7 FF extensions running.
Re:Total cached page limit. (Score:5, Interesting)
People have written garbage collectors for C++, and they work just fine. But they do not help with fragmentation, which is the problem you're describing. That requires a heap-compacting allocator (aka a "handle" allocator). Many languages with garbage collection also use a heap-compacting allocator. C++ does not, because of a low-level language "feature": pointers, and specifically, pointer arithmetic.
If an object moves in memory, then people have to be notified that it has moved, or they won't know where to access it. Languages like Java handle this behind-the-scenes; the system library tracks objects for you, and your program never knows (or cares) whre an individual object is.
C++ allows direct access to system memory, and it tells you precisely where your objects are located. Programmers are then free to do all kinds of things like compute distance to other objects, or convert the location to a number and do arbitrary math operations on it.
When an object moves, anything that refers to it needs to be updated. Well, good luck figuring that out in a language with pointer arithmetic! The system would need to magically determine whether or not a numeric value was actually a memory locations. And what if a program computed the distance between two objects, and later on used that distance to get from one object to the other? The system has no idea of what can be safely moved, and what has to stay put. So nothing can ever be moved.
There are workarounds of course -- if you write a program with heap-compaction in mind, then you can use a "handle" system, where every object has an ID. You remember the ID, and to access the object, you ask the system for a temporary memory location. And as soon as you're done, you "forget" the memory location and let the system shuffle things around in memory. The next time you give that ID to the system, you might get back a different memory location, but you were already expecting that so your program doesn't mind.
But handle allocation is slower, less efficient, and more annoying to use than a traditional fixed-location allocator. You have to start your project with it in mind; retrofitting existing code to use a handle allocator is a giant timesink and prone to conversion errors. And if you don't mind the loss of performance due to using a handle allocator, why are you using C++ in the first place?
POST data? (Score:3, Interesting)
This explanation makes no sense (Score:2, Interesting)
If I leave my computer on and come back the next morning, with no new pages having been loaded, the browser is suddenly taking up like 400 megs of RAM.
That can't be explained by caching tabs.
Re:Total cached page limit. (Score:3, Interesting)
I used to use this years ago on machines like the archimedes that had little memory. In a modern paged system it's a nearly useless technique - the most you'll lose is a single page even if there are large 'gaps' in the virtual address space.
Re:Firefox performance slowed to a crawl (Score:3, Interesting)
I think we've no got to the state where Firefox can be seen as a nice try, but no cigar. Opera on the other hand just works - and increadibly it's quick and lean too.
I've no connection with Opera, just like many I've been through the "Dump IE, Use Firefox, Think Firefox is wonderful, Find Firefox's dreadful memory/cpu cycle leaks, Dump Firefox" cycle!
You call it a bug we call it a feature (Score:3, Interesting)
If this feature is for my benifit then let me decide whether to use it or not. Apart from that it does not explain why when I leave firefox idle with only one window open on a simple HTML page over time my memory useage goes up...
Stop hiding behind feable excuses and actually work on reducing the footprint firefox uses... FF is suposed to be a lightweight browser alternative to the usual browser bloatware - it is failing at the moment (rather like my spelling
Re:Total cached page limit. (Score:2, Interesting)
Actually, neither of these things are guaranteed to work by the C++ standard. Implementations usually make it work, because it's more easy than not and occasionally convenient.
I think you could do a heap-compacting implementation of C++. Unlike conservative garbage collection, however, you can't do it in a library. Pointers would double in size and become handle-offset pairs, plus an entry in a map for each heap block. Every pointer access would also take a second indirection. As a side benefit, this makes garbage collection and bounds checking a little easier.
Things like taking the difference of pointers to two objects not in the same array would not work, but C++ doesn't guarantee it anyway. Converting pointers to ints and back wouldn't either, but same deal.
But the problem is, someone needs to implement it. And that someone needs to also have a compiler that they can modify in terrible, terrible ways. It also would help to be an expert in designing thread-safe, interruptable heap compaction algorithms.
Now, if you were in a position to do that, would you bolt this on to C++, or would you put that effort into a different language?
Re:Total cached page limit. (Score:1, Interesting)
Fasterfox's Clear Cache function helps (Score:3, Interesting)
It may be a feature, but it's still undesirable (Score:2, Interesting)
Considering the hooplah that goes along with it, firefox underperforms on basic tasks when compared to KDE's Konqueror.
What's worse is that this command firefox ./index.html tries to open http://index.html/ rather than file://index.html. Meanwhile Konqueror behaves correctly.
Competition (Score:3, Interesting)
When they do it the get slapped for using too much resources?
But I see a good point. I also would like to see new developement halted for some time to catch bugs and security problems. This would also help plugin developers to catch up. New features could be developed in plugins anyways.
Re:Total cached page limit. (Score:2, Interesting)