Closed Bug 353644 Opened 18 years ago Closed 18 years ago

Replacing the Image object src property doesnt free previous image memory.

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
1.8 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: pistolinio, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; pl; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; pl; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

When you create an Image() object and set it src property, it takes some memory, but if you are going replace it over and over again, the memory amount taken by firefox immediately grows. When i made an application with 40 images which src properties change when some event occurs, after few minutes it takes about 100mb of my memory. Please check the link which demonstrates the problem.

Reproducible: Always

Steps to Reproduce:
1. var img = new Image()
2. /* place it somewhere in DOM model */
3. img.src = 'some_page';
/* memory usage grows */
4. img.src = 'some_other_page';
/* memory usage still grows */
5. img.src = 'some_another_page';
6. (...)
/* now we have a lot of memory taken */
n. img.src = 'final_page';
/* in my case it stops somewhere about 100mb memory taken */

Actual Results:  
firefox memory usage: almost 100mb

Expected Results:  
I think it should remove previous pictures from memory and cache it locally on the disk. I checked it in opera an ie and there is everything ok.
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.8 Branch

*** This bug has been marked as a duplicate of 228233 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
This probably isn't a duplicate.  Bug 228233 is about the src being set multiple times in a row with nothing happening in between.  In this bug there's a 1-second timeout...

If this is a problem on trunk we need to investigate what's going on here.
Status: RESOLVED → UNCONFIRMED
Depends on: 228233
Resolution: DUPLICATE → ---
So wait.  All the images are different.  You sure it's not just the image cache filling up?  How much memory do you have?
(In reply to comment #3):

I have 1GB memory. Theoriticaly it could be caching, but if it was, why it takes so much memory? I have application similar to google maps. When the map moves, the images src properties are replaced with the new ones, and when i have 25 image objects in rectangular 5x5 for example, and when i move the map, memory usage jumps very fast sometimes to 150mb and sometimes stays on 100. I think, if it would be caching, garbage collector should free some memory.
> I have 1GB memory.

Then in Firefox 1.5.0.x builds the memory cache will be 32MB.

Is the memory usage stabilizing for you consistent with that?

Note also bug 296538.

> I think, if it would be caching, garbage collector should free some memory.

There is no GC.  Things are evicted from cache if something else needs to be cached.
(In reply to comment #5)
> Is the memory usage stabilizing for you consistent with that?
No, it isn't. The memory grows to 100mb or above and sometimes frees few MB, but is still much bigger than expected 32MB.

(In reply to comment #0)
Only one object, but for cache, many images are loaded by single page.
It seems to be similar situation to Bug 213391 for memory cache.
> Necko/Gecko needs to enforce a maximum for total size of image/memory cache

To Artur Wasilewski(bug opener):
 Have you checked about:cache display? (before "step 0." and after "step n.")
 - about:cache/Memory cache device
     What value is set in "Storage in use:"?
 - about:cache/Memory cache device/List Cache Entries
     Key: entry for all images?
     What value is set in "Data size:" for image?

(In reply to comment #7)
>  Have you checked about:cache display? (before "step 0." and after "step n.")
>  - about:cache/Memory cache device
>      What value is set in "Storage in use:"?

Before step 0: Storage in use: 317 KiB
After step n: Storage in use: 31673 KiB

>  - about:cache/Memory cache device/List Cache Entries
>      Key: entry for all images?
>      What value is set in "Data size:" for image?
After "step n." every image has "Data size: 262144 bytes", it means exactly 256 KB. One image? It takes on the disk only few KB in PNG format.
> The memory grows to 100mb or above

And keeps growing, or stabilizes?  And is that total memory?  Or memory above what the memory usage was when the browser just started?  If this is total memory, what _is_ the memory usage when the browser just started?

> It takes on the disk only few KB in PNG format

PNG is a compressed format.  The memory cache stores uncompressed 32-bit images... There are other bugs covering that.

In any case, I just tried the testcase (after removing the "console" thing that makes it not work at all) and the memory growth I see over here looks like the cache filling up.  There are definitely no shutdown leaks (though that doesn't mean there aren't any application-lifetime leaks).

Artur, just to make sure we're on the same page, you don't have any extensions installed, do you?  If you do, do you still see this bug in safe mode?
(In reply to comment #9)
> And keeps growing, or stabilizes?  And is that total memory?  Or memory above
> what the memory usage was when the browser just started?  If this is total
> memory, what _is_ the memory usage when the browser just started?

When the browser starts, it use 20mb memory. When I load new images, the memory usage grows to something about 100mb and stabilizes on this level.

> Artur, just to make sure we're on the same page, you don't have any extensions
> installed, do you?  If you do, do you still see this bug in safe mode?

Yes, I started the browser in safe mode and the bug exists too. I know it is browser's caching, but why firefox takes so much memory, it should take 32mb and it takes 3 times more.

(In reply to comment #0)
> firefox memory usage: almost 100mb
(In reply to comment #4)
> memory usage jumps very fast sometimes to 150mb
(In reply to comment #10)
> it use 20mb memory.
> usage grows to something about 100mb

What do you mean by your "memory usage"? Value where displayed?
To bug opener: Completely same question as Bug 320915 Comment #42.
(In reply to comment #11)
> What do you mean by your "memory usage"? Value where displayed?

I mean the value displayed on task manager
Firefox (safe mode), config.trim_on_minimize = true
Firefox state / Memory usage / Virtual Mememory Usage
Clean firefox instance / 25 / 14
Running my aplication / 38 / 27
Testing the bug / 64 / 53
FF just minimized / 1 / 55
3 secons later / 3 / 55
10 seconds later / 18 / 55
Firefox restored / 32 / 55
Testing the bug again / 53 / 53

> Is there any difference among number at step 3-0, 3-2, 3-5 and step 3-6?

As you can see, there is a difference.

> Is there any difference from result when same test with  config.trim_on_minimize = false ?

Yes, when window is minimized, memory usage falls down.
> Firefox state / Memory usage / Virtual Mememory Usage
> Testing the bug / 64 / 53

Oh.  Task Manager is just lying to you; this is a known problem.  Firefox is more or less using 53MB of memory there (not quite; see some comments by dbaron in other memory bugs about what the numbers Task Manager reports do and do not mean), but Windows has allocated 64MB to it.  Firefox isn't using the whole 64MB, though, and if Windows decides it needs those extra 11MB for some other app it can take them any time it wants to.
Ok. Well, I think that's all about that. I was wondering why this bug doesn't occur on Linux, and as I can see, it is not firefox' fault but windows'. Thanks for the help.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → INVALID
(In reply to comment #14)
> Task Manager is just lying to you;
Boris, really?
I think Task Manager of MS Win is very honest. Value displayed in Task Manager's window is same as "Counter Log" of "Process" by performance tool of MS Win. 
I think this is "Design" of MS Window's Memory Management, which is poor for me although I think partially reasonable because OS for Desk Top.
 - MS Win's Memory Management doesn't release(put it to page pool) real momory
   which is allocated to already freemain'ed virtual storage used by application
   until application's window is minimized(trim_on_minimize=true case) or until
   real memory shortage is detected by MS Win(both trim_on_minimize=false and
   true cases).
   I think this is mainly performance reason, and is reasonable when Desk Top
   except for virtual memory waster, real memory eater only if MS Win, like
   Mozilla :-)
Is this wrong?

> I think Task Manager of MS Win is very honest

One can lie while being completely honest.  For example by labeling your columns in ways that users are guaranteed to misunderstand.
(In reply to comment #17)
> > I think Task Manager of MS Win is very honest
> One can lie while being completely honest.
"Return Ace" like Agassi! MIT's has training course for it? :-)
"Memory Usage" column is "Working Set" property of "Process" object of "Counter" when MS Win NT or later.
This size(really allocated memory) depends on MinimumWorkingSetSize and MaximumWorkingSetSize specified in WINAPI SetProcessWorkingSetSize issued by application.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setprocessworkingsetsize.asp
When trim_on_minimize=true and Mozilla is minimized, MinimumWorkingSetSize=x0F...F & MinimumWorkingSetSize=x0F...F seems to be requesed by Mozilla.
I don't know what is requested when trim_on_minimize=true and window is restored or when trim_on_minimize=false.

Boris, is there any possibility of improvement by specify Minimum/Maximum-WorkingSetSize appropriately?
( For example, Maximum=1/2 of Virtual Memory Size currenyly using, Minimum=1/4 )
( of Virtual Memory Size currenyly using. Half of Virtual Memory Size looks to )
( be working set size really required to run without severe response delay.    )
 
Read "x0F...F" as "0xF...F", please. Sorry for spam.
You need to log in before you can comment on or make changes to this bug.