User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022806 Minefield/3.0b4pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022806 Minefield/3.0b4pre First of all, let you can presuppose the following: I understand that when config.trim_on_minimize is set to true, it just lets Windows manage the memory like it would with any other program. Firefox by default, bypasses Windows default memory management behavior to obtain a performance boost such that Firefox has the best responsiveness it can have when the window is restored. Therefore, for most people, it is best to leave this setting set to false. With that said, if you multitask on a memory limited machine, you might WANT Firefox's memory to be cached to the hard disk on minimize, such that it frees up available RAM, in advance, with the knowledge that you will be switching over to another program which may need that RAM. This is when I think someone would want to have it set to true. The problem that arises is as follows, and whether or not this is buggy behavior, you be the judge: When I minimize the current nightly build with the setting being true, Firefox's memory is initially drops, but then goes right back up to where it was after a couple seconds. Shouldn't it remain trimmed? The problem here could be two things: Either the name of the setting is ambiguous, and should be changed to clarify that it is actually just a setting to: "config.let_OS_manage_memory_on_minimize", allowing for the case I am experiencing where there is a proper scenario when Windows will not keep the memory allocation trimmed on minimize, even when this is set to true, OR, there is a bug here, and the memory allocated to Firefox SHOULD actually remain trimmed until the window is restored. FYI, I have tested this with no extensions. Reproducible: Always Steps to Reproduce: 1. Start up Firefox 2. set config.trim_on_minimize to true 3. watch the memory allocated to Firefox in your task manager before and after minimizing Firefox Actual Results: The memory allocated initially drops, but then jumps back up to where it was. Expected Results: The memory allocated remains trimmed until the Firefox window is restored, else, the setting should be renamed to remove this ambiguity.
The reason why config.trim_on_minimize is by default false (and why it is NOT recommended to set it to true), is bug 76831 and bug 299578 Contrary to what you say, config.trim_on_minimize will not "cache your memory on disk". It doesn't even free RAM : the "Mem Usage" column in Task Manager drops, but "Virtual Memory Size" stays the same. The memory seems to come back when Firefox touches the memory again, because it was never freed in the first place (!!!) The name "Mem Usage" on that column is really a big fat lie. Change config.trim_on_minimize as much as you like, but you won't shrink the real memory usage of Firefox. Really.
I understand this. I hoped that you and others wouldn't take how I described the behavior the wrong way, in other words, in the usual misunderstood way that comes up when people talk about this option. That is why I prefaced the above how I did, to sidestep this semantical discuss of what is actually done with the memory. Let me tell you, I have no "hopes" that this option does anything different than how it is described at http://kb.mozillazine.org/Config.trim_on_minimize . The misunderstanding may just be in the semantics and terminology of how I put it, but I have already in the past gone over exactly what you just described for me with others in the past. I don't hold any hopes of this option doing anything genius or anything. It does what it does. Firefox doesn't "cache your memory to disk". I completely understand that. What I am referring to here is with regards to how Windows will deal with the memory on minimize, if the setting is set to true. Based on what you said, if Firefox plays no part specifically in the "trim", then it would be useful to know if the behavior that I have described above is contrary to what should be happening, otherwise, like I said, it would be prudent to name the option in a manner similar to how I have described above as to avoid this same kind of confusion in the future. My question remains: Should the memory usage value drop AND remain trimmed in Windows XP on minimize UNTIL the Firefox window is restored, when this option is set to true?
And when I said "cache" above, I meant to say "swap", as per http://kb.mozillazine.org/Config.trim_on_minimize , and this is all in the context of the OS being allowed to do it BY way of this Firefox setting, and NOT the Firefox code physically having anything to do with it.
The reason why the memory seems to come back, is that it's only marked as 'preferably swappable', not really 'swapped' out (which is what you think). When the application will touch the memory again (for example when performing garbage collection), then it will be marked an 'recently in use', and that's why it seems to be swapped in again. The problem is that you can't guarantee the application will never touch a certain memory page again, so that it will be never be used again. Firefox is still active, even when minimized.
(In reply to comment #4) > The reason why the memory seems to come back, is that it's only marked as > 'preferably swappable', not really 'swapped' out (which is what you think). > When the application will touch the memory again (for example when performing > garbage collection), then it will be marked an 'recently in use', and that's > why it seems to be swapped in again. The problem is that you can't guarantee > the application will never touch a certain memory page again, so that it will > be never be used again. Firefox is still active, even when minimized. > Look, I don't think that it does anything. I know there isn't some magical difference in memory when using this setting. I am simply restating what it says on that mozillazine page. That isn't the point of this bug report. All that needs to happen is an answer of my one question above. Simply stated, if there is no definitive expectation that Firefox can control whether or not the memory will be trimmed on minimize, or that it will remain so until the Firefox window is restored, then the option should be renamed as to not insinuate that this is the case, to something like "config.let_OS_manage_memory_on_minimize". This would solve all your problems and stated angst toward the people who DO think this option is some type of voodoo magic for memory.
" The problem is that you can't guarantee the application will never touch a certain memory page again, so that it will be never be used again. Firefox is still active, even when minimized." Based on that, I understand you to say that the memory is probably being accessed again by Firefox while it is minimized, causing the value to jump back up. That is the very thing that I am getting at. Yes, currently we supposedly can't guarantee that Firefox will never touch a certain memory page again while minimized. The ambiguity of this setting makes one think that Firefox CAN do that. I would argue that it might even be possible to implement that feature into Firefox, to have Firefox NOT touch its allocated memory pages while minimized. Furthermore, the current wording of the setting I think implies that Firefox DOES do this when this setting is true. That would be a more practical usage for this option. So, to conclude, let me make sure I am understanding you properly. You are saying that there is no way currently in Firefox to definitively have the memory usage value drop on minimize and remain trimmed and untouched in Windows XP for the duration of Firefox being minimized? If that is the case, then I suggest that this option be renamed to remove this very large possibility of misinterpretation.
(In reply to comment #6) > So, to conclude, let me make sure I am understanding you properly. You are > saying that there is no way currently in Firefox to definitively have the > memory usage value drop on minimize and remain trimmed and untouched in > Windows XP for the duration of Firefox being minimized? Absolutely. It's is not possible to trim memory, you can't have holes in your memory map. The only exception is memory that is allocated at the edge of the memory map (the memory map can then shrink slightly), but the chance that this happens is very small. The main problem in Windows is that the Task Manager is lying in its interface, and that the minimize action in most applications has a visible effect. But it doesn't really do anything - it only says that the application is now a candidate for being swapped out (that was useful in the Windows 95 days). But when an application touches the memory again, then that part of memory will be marked as active again, and the memory usage seems to grow again (but that's an illusion). Applications that do a lot of stuff in the background will seem to jump right back again, but in reality nothing really changed (look at your hard disk light - it didn't even blink !). I'm in favor of removing the settings completely - it doesn't do anything anyway. Note that Firefox 3.0b4 uses a different memory allocator (jemalloc), which has less problems with memory fragmentation. The main advantage is that memory will grow less often (there's more room for larger blocks without growing the memory map). But another effect is that it will leave larger holes in the memory map, and as a result, it will stay away from certain memory pages for a longer time (as long as the memory is not used for a new block). As a result, it will seem that this part of memory is trimmed from the application. The memory usage of the current version seems to jump up and down much more than previous version, but it's actually the same illusion as before, since the memory space remains the same (or grows not so fast I must say).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Allocated memory does not remain trimmed when Firefox is minimized and config.trim_on_minimize is set to true → config.trim_on_minimize should be renamed or removed, as its naming is ambiguous and Firefox cannot truly do what its name implies, unless further features are implemented
Component: Preferences → Widget: Win32
Product: Firefox → Core
QA Contact: preferences → win32
Version: unspecified → Trunk
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 369002
You need to log in before you can comment on or make changes to this bug.