Slashdot Mirror
Firefox Memory Leak is a Feature
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."
So there's a way to limit the number of cached pages per tab, but no way to limit the total number of cached pages, for those of us who have fifteen tabs open?
Whoops!
tasks(723) drafts(105) languages(484) examples(29106)
Hard choice but I'm seriously looking at Opera after seeing this I have a gig of RAM and its still laggy, I was wondering why the 'leak' was so high theres no way you could put that much bad programing to make a programe eat memory like a fat kid in a pie shop.
If this is true, then why is so little memory freed after the tab is closed, compared with how much it consumed when it was created?
If you don't know where you are going, you will wind up somewhere else.
how about a configurable option to not take up 200mb of ram? keep it as-is by default, but let power users toggle it off
Why does Opera do the same thing faster without the memory penalties?
FanFictionRecs.net
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.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Uh, using a lot of memory is not the same as a memory leak.
Uhuh. It's the same with Google.
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.
An application cannot release memory in the middle of the heap without also releasing the memory at the end of the heap.
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.
> Wouldn't all pointer references then have to go through some kind of lookup table, so that the objects could be relocated by the runtime without breaking them?
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.
Excellent post, well worth the +5.
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).
A Man's ethical behavior should be based effectually on sympathy, education, and social ties -- Albert Einstein
Memory isn't an unlimited resource you just hoard whenever you think you need it. Right now my instance of firefox is taking up 128 megs! I've seen it up to 256 megs before. This is just simply insane. I've seen people who's computer performance has gone down the tubes because firefox is taking up all the memory (and these are machines with 512 megs of memory, not exactly tiny). What I'd like to convey to the firefox devs is this: Your application isn't the only one running on the system. Play nice and don't be a hog.
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?
AccountKiller
The cache feature is nice, but why distribute it out to every tab? If I have 20 tabs open I'm not going to be constantly clicking the back button on each of them. Why not clear the cache on tabs that haven't been accessed recently and only keep cache on tabs actively being used. Often when I open new tabs I just want to be able to quickly access that page, or use it as a temporary bookmark - not navigate back through the path that got me there.
Find coupons in Greeley
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.)
Opera uses disk cache and ram cache. It uses as much ram cache as it can for the speed benefit, and on older systems with less memory it tones down the ram cache usage to avoid stepping on toes. In any case how much disk and ram cache it uses can both be controlled manually from the preferences. Ram is set to auto by default meaning it will take a percentage of the free memory for itself. On my 1gb system it tends to use about 90-120megs of ram if I've been browsing for a while, but it does keep a cap even on that system so it never gets so large that it gets bogged down. Then on systems like the one I am on right now that has 128mb ram, it relies mostly on disk cache and doesn't really suffer any hits in performance for it.
1 (short ton / firkin) = 89.1432354 slugs / keg
Welcome to the real world. If QA cannot duplicate a bug, then the chance that it'll be taken seriously is low, let alone being fixed. They don't have all day for one bug that's not reproducible by them.
Every time I close all the tabs in my browser session except two or three, then check a few hours later and see that Firefox is sluggish and hogging a few hundred megabytes, I go to the police and ask them to take me into protective custody. I'm obviously a danger to myself and others. When I'm not responsible enough to seek psychiatric help, I just stare at my monitor and tell myself, "You only see three tabs there, but that's because you're crazy. You still have all those dozens of porn tabs open. You just can't see them because you went blind masturbating."
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.
Its a non-issue. As explained on a note at the end of the article, its a per session setting, not per tab, so the entire article misrepresented the "feature".
"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.
Carol vs. Ghost
The good news is that a false positive isn't going to cause direct harm in mark and sweep. All that happens is that space that could be used isn't
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.
If your CPU/Memory problems persist in Outlook, et. al., then I posit the problem is NOT Firefox, but instead an OS library gone awry. Why? Those other programs use IE whether you like it or not. If it affects IE, then it is a library used by both Firefox and IE.