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."
Total cached page limit. (Score:5, Insightful)
Whoops!
spyware with IE or memory leak with FF.. (Score:2, Insightful)
Doesn't seem to be true (Score:4, Insightful)
about:config (Score:3, Insightful)
So I'll be the first to say it.... (Score:5, Insightful)
Re:Total cached page limit. (Score:5, Insightful)
What I'd like Mozilla devs to do (Score:5, Insightful)
Before someone jumps at my throat, it's just a description what I'd like to see, but of course its all up to the developers, they decide what to code and do with their time. It is just simple user feedback.
Re:Total cached page limit. (Score:2, Insightful)
Me, I'd like to limit it to 25 cached pages, and have the old ones shuffled out as new ones are shuffled in.
Huh? (Score:5, Insightful)
Re:Wow. If this excuse had come from MS... (Score:0, Insightful)
One minute we're all pro-civil liberties, pro-free speech, anti-censorship, anti-repression but the moment Google wants to do business in China, 'they're only following the laws of that country', they're doing nothing wrong. Switch with Microsoft and they'd be 'dealing with an evil regime, shame on them' yadda yadda.
Same with Nintendo. Bash Microsoft and Sony for coming out with unoriginal sequels yet Nintendo are such innovators for bringing out Metroid Fusion, Super Smash Brothers Melee and Super Mario Rainbow Warrior.
Re:releasing memory (Score:2, Insightful)
That's not strictly true. If the hole is larger than 4k (or 8 if it's not page-aligned), there are two things that can be done.
You can decommit the page, but keep it reserved. This frees RAM, decreasing the process's memory usage, but still takes up some of its address space. You MUST coalesce free heap blocks in this case, because all data in those pages is lost. This also requires extra housekeeping.
Or you can keep it committed, and the OS will push that memory out to the page file. This is done pretty much automatically, but it's more lazy. In Windows, you can somewhat force this by minimizing all windows owned by the process.
The best solution to this problem is to use a compacting garbage collector.
Unless you've done actual research, I wouldn't be so quick to say that. It's certainly the easiest solution if you're using a language that doesn't use real pointers, but there are numerous possible solutions.
Eg, you could allocate pages for large objects like this directly from the OS rather than using a heap. Then freeing objects in the middle is no problem at all.
Re:releasing memory (Score:5, Insightful)
Only on a computer without virtual memory. In a PC (which *has* virtual memory), you just punch holes in the memory.
What happens is a process gets an "address space", into which pointers can point, but any given address may not map onto some real storage. The process asks the operating system to map a range of addresses onto real storage which the operating system will try to map to real fast memory when it thinks it will be used at any moment. When the OS figures the memory wont be needed for a while, and something else needs some memory, the OS copies the data to disk and redirects the mapping to a proxy that will pull the data back into memory when the process tries to use it again.
When a process knows that it won't need a section of that real storage, it can tell the operating system to unmap it from the address space.
There are various other things that go on, but that's the simple story. From a figure posted in an earlier message, it seems that opera does pretty damned well (in comparison to most modern programs) with just the simple story, not having to rely much on nasty unreliable heuristics. Of that I am impressed.
Re:releasing memory (Score:3, Insightful)
But you pointed out the flaw in the wording of the article - this IS NOT a memory leak, just inefficient use of the heap.
I thought the definition of a memory leak was an application that kept allocating memory from the OS as it ran, not an application that asked for a chunk of memory and just reused it inefficiently?
(If I'm wrong, someone please correct me).
Firefox developers don't "get it" (Score:5, Insightful)
With the number of people complaining about this (and the number of people that don't even KNOW to complain) isn't it a safe bet that you've made a mistake in the amount of cached pages?
Doesn't this just seem silly? (Score:3, Insightful)
Re:So I'll be the first to say it.... (Score:1, Insightful)
You sound like you've never actually picked up Opera and used it...
Unlike FireFox, Opera's features don't ever seem to add bulk to the interface. I'm continually impressed with the elegance of the UI. The downside on that one is that configuring these features isn't as slap-you-in-the-face obvious as it is in FireFox, although just as powerful.
Opera has a 'feature' just like Thunderbird integrated that I never use... and if I didn't read the development logs, I wouldn't even know it existed.
I've never found a FF extension which added a genuinely useful feature that wasn't already in Opera, with the exception of GreaseMonkey, (which enjoys full support in the upcoming 9.0 release).
Re:bfd? (Score:5, Insightful)
Virtual memory is not a carte blanche for memory hogging. As you should know, memory hogging will result in degraded performance.
Assuming that users have unlimited resources is exactly how Mozilla is barely usable on Windows 95-ME - especially when you have Slashdot Moderator access.
In an ideal situation, that would be correct.
However, the operating system does not know which memory is currenly "in use" and which ones are "in cache" - in fact, it's quite easy for an "in use" to be physically sandwiched between two "in cache" entries. Because of this, you will have a sudden loading time if you do plenty of other tasks in the background and suddenly switch back to Mozilla.
Small applications, being small, do not generally have to wait 1/2 seconds to recover from being pages in or out. Since Mozilla allocates the cache in memory, it will have to wait those two seconds.
An OS with decent vmem support would allow you to map files to memory. This results in no swapping at all - only writing perodic output to the hard drive, and loading the file into memory as required. If another application needs more memory, the memory map is discarded with no need to write the contents of memory.
An application that doesn't exploit the usage of memory maps is as good as an OS with shoddy vmem support. (Of course, it can simply use it's disk cache for the same effect.)
Re:Obviously there is a memory penalty with Opera (Score:2, Insightful)
Re:Firefox developers don't "get it" (Score:4, Insightful)
Re:Your usage pattern is different. (Score:1, Insightful)
I'm definitely insane (Score:3, Insightful)
Seriously, what's with all the song and dance? Firefox obviously has at least one problem, probably several, that leads to bad performance for many users, under certain circumstances. Call it a UI problem, call it a documentation problem, I don't care, just call it a problem. Don't call it a feature or a misunderstanding. Don't pick a feature that can't account for many of the reported problems and say, "Aha! This is THE Firefox memory leak that's bothering everyone. See? It's a feature!" The denials and talk-arounds on this issue are what you would expect from a political party, not an open-source software project.
Of course, I only know all this because I use Firefox. It's the best. The memory problems would only be a minor annoyance if I didn't have to constantly read about how I'm crazy or stupid.
Per Session, not per Tab (Score:3, Insightful)
"Edit: In the comments, Boris and David pointed out that I misread the code, and that this is a global preference so that there are no more than 8 cached pages for the entire session, not per tab. My initial posting had claimed that it was per-tab. Oops!"
If Firefox has memory leaks (and I think it does), this is not what is causing it. If it were, however, per tab, as the article originally claimed, then it would have been a problem, because the more tabs you open, the memory usage increases at an alarming rate, if it has to keep up to 8 history pages cached.
Nothing to see here. Move along.
-dZ.
Re:releasing memory (Score:3, Insightful)
Or an allocated page leaks. While the collector's "blacklisting" approach minimises the amount of this that happens, it does still happen from time to time.
Boehm claims this is irrelevant in today's operating systems with virtual memory, although I doubt you'd see an entire page's worth of false positives.
I'm not entirely sure I agree with him. Consider, for example, applications that store large arrays of seemingly random data on the stack (e.g. compressed data). As the amount of this data tends towards (2^32/PAGESIZE)*4 bytes (= 2^24 bytes, or 16Mb), the number of pages blacklisted should approach half of available virtual memory, reducing to 2Gb the memory available for the application on a 32 bit address system (i.e. todays standard). 2Gb is a lot, but many applications are starting to get close to that. And doubling the amount of randomised data on the stack will halve it, I think.
Boehm does most of his work on 64 bit platforms these days. I'm not surprised that he's unconcerned about virtual address space usage.
That said, it's very simple to avoid this pitfall: use GC_MALLOC_ATOMIC to allocate any space that will store apparently-random data. You just have to understand how the garbage collector works, and code around it, to avoid such problems. I guess we're looking at a leaky abstraction here, as always.
Re:Total cached page limit. (Score:3, Insightful)
Thank you. My machine has 512 mb RAM (planning ot upgrade soon) and I multi-task a lot, so when I'm running FF I'm almost running 1 or 2 other programs at the same time. That's why it's very high use of memory becomes a problem. And with a fast connection like I have now, I can't tell that my page load performance is suffering at all.
But... what they should do is to put this in the regular optios menu instead of about:config. Lots of users don't even know to use about:config. I really like FF but the "we know better than you" attitude of the Moz team is starting to bug me. No, it's my machine and I know what I want to do with it, so I think I just might know better than they do.
Re:Why does Opera work well, and not Firefox? (Score:1, Insightful)