123191 - Mozilla doesn't release memory used to render prior pages

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Dom Incollingo]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
Gecko/20020201
BuildID:    2002020103

When displaying several memory-intensive sites (lots of images, applets, etc.),
Mozilla memory consumption increases.   After returning to a site that does not
require much memory (mostly simple text), Mozilla does not release unused memory
that was allocated for rendering previously viewed sites.

Reproducible: Sometimes
Steps to Reproduce:
1.Launch Windows Task Manager.
2.Launch Mozilla and navigate to http://www.yahoo.com/.  (This site does not
require much memory to render.)
3.Mozilla memory utilization is at about 18 MB.
4.Navigate to http://java.sun.com/
5.Navigate to http://www.visitor.calgary.ab.ca/
6.Navigate to http://www.netscape.com/
7.Navigate to http://www.java-pro.com/
8.Navigate to http://www.gentleware.com/index.php3
9.Allow each of the above pages to fully render and wait a couple seconds before
navigating to the next page.
10.After the last page has rendered, check Windows Task Manager. Mozilla memory
usage is at 41MB.
11.Return to http://www.yahoo.com/
12.Wait a few seconds and then check Windows Task Manager.
13.Mozilla memory usage is at 39 MB.  It remains at 39 MB for several minutes
(perhaps indefinitely).

Expected Results:  After returning to http://www.yahoo.com/, Mozilla memory
usage should have dropped to the 18 - 20 MB range, since Mozilla was initially
able to render this site with 18 MB.

I have encountered this problem (unreleased memory after heavy surfing) on
several occasions.  It is generally sporadic.  Sometimes Mozilla releases
memory, and sometimes it doesn't.  But by following the above steps, I have been
able to reproduce this problem three times in a row using build 2002020103. 
FYI, I have 512 MB of RAM.

Comment 1

[Dom Incollingo]

Attachment: Initial memory usage at http://www.yahoo.com/

Comment 2

[Dom Incollingo]

Attachment: Memory usage after rendering five additional sites

Comment 3

[Dom Incollingo]

Attachment: Memory usage after returning to http://www.yahoo.com/

Comment 4

[Boris Zbarsky [:bzbarsky]]

Dom, what's your memory cache size set to?  Do you have the java plugin?  Is the
number for mozilla including the JVM size?

Comment 5

[Dom Incollingo]

My memory cache is set to 1024 KB.   I am using java plugins.    My JRE is 1.4.0
beta 3.  

I can't tell what the JVM size is.   When I return to http://www.yahoo.com/
after visiting the 5 sites listed above, Windows Task Manager has an entry for
mozilla.exe.  The Mem Usage column for mozilla.exe is 39,676 K.   There is no
entry in Windows Task Manager for javaw.exe.

One more thing I noticed today.  If I leave the Mozilla window open after
returning to http://www.yahoo.com/, Mem Usage for mozilla.exe stays at about
39,676 K indefinitely.   But if I minimize the Mozilla window (minimize button
in upper right), memory is released!  Mem Usage for mozilla.exe drops to about 7
MB, then slowly rises back to about 20 MB.   This seems to be the normal range
for displaying http://www.yahoo.com/.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Could you try disabling java and performing the same experiment?
Does the memory usage jump on a particular intermediate page, by the way?  Or
does it slowly climb?

Comment 7

[Dom Incollingo]

I reran the test twice: once with java disabled, and once with java enabled.  I
recorded Mozilla memory utilization (Mem Usage for mozilla.exe) after each page
was  displayed.  By the way, I also cleared the cache (memory and disk) before
starting each of the two tests.  Here are the results:

Java Disabled
http://www.yahoo.com/                 17.6MB             
http://java.sun.com/                  18.9MB
http://www.visitor.calgary.ab.ca/     19.7MB
http://www.netscape.com/              20.6MB
http://www.java-pro.com/              25.2MB
http://www.gentleware.com/index.php3  22.4MB
http://www.yahoo.com/                 20.6MB
(Usage stayed at about 20.x MB as long as I remained at www.yahoo.com)

Java Enabled
http://www.yahoo.com/                 18.1MB
http://java.sun.com/                  36.1MB
http://www.visitor.calgary.ab.ca/     37.4MB
http://www.netscape.com/              38.7MB
http://www.java-pro.com/              44.1MB
http://www.gentleware.com/index.php3  39.8MB
http://www.yahoo.com/                 38.4MB
(Usage stayed at about 38.x MB as long as I remained at www.yahoo.com)

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK... so looks like Mozilla's memory usage grows by 3MB, of which 1MB is memory
cache...  The rest of the increase you see is that we start the java plugin when
you visit java.sun.com and then never shut it down (this behavior is by
design).  Task Manager is lumping the java plugin's memory use in with
Mozilla's...

Comment 9

[Dom Incollingo]

I have one related question.  On a few occasions I have been using Mozilla for
over an hour and noticed that memory usage was quite high (70MB - 100 MB).  I
had attributed the high memory usage to Mozilla.  But I am sure that I hit a
site with applets along the way, and that would have started the java plugin. 
Is it possible that a lot of this memory was caused by the java plugin?   Could
memory usage continue to grow over time as the result of having the java plugin
running and continuing to navigate to various sites?

I will disable java for a few days, and continue to run various tests and
monitor memory usage.

Comment 10

[Michael Gabriel]

im running mozilla 0.9.8 with quicklaunch and i usually dont reboot my machine.
after 1 day of work i have to quit mozilla and restart it cause its using so
much memory that win2k is telling me its running out of ram. thats usually
around 400megs real and 800megs swap. thats TOTALLY unacceptable for a
commercial product.

Comment 11

[Michael Gabriel]

since the memory use seems to get worse and worse. the more extreme does this
problem become. like now my mozilla is using 80megs real and 1.1 gig swap, win2k
is swapping it out, but its not being freed till i close mozilla.

Comment 12

[Peter 'vt100' Schwindt]

I tested this using build 2002052606 - I opened the list of all UNCO bugs for
Windows... --> Mozilla using 198MB RAM. Now, after closing that tab, there are
still 196MB in use

Comment 13

[Boris Zbarsky [:bzbarsky]]

Peter, you are almost certainly seeing bug 130157, which actually has an
explanation for where the memory is (Mozilla _has_ released it).  I don't know
what Michael is seeing, but it's not what the original reporter here reported....

This bug needs to be assigned usefully; leaving it in browser-general isn't
going to get it fixed.

Comment 14

[timeless]

.

Comment 15

[Christopher Hoess (gone)]

sending to Plug-ins, which appears appropriate for original report.

Comment 16

[rubydoo123]

assigning to AV - Andrei, I am suspecting that what this person is seeing is
similar to the complaints in bug 132759, even though this is about applets
instead of Flash

Comment 17

[rubydoo123]

reassigning to OJI folks for some input here. It seems that java VM takes up
20MG on the get go. Is there anything that can be done about this?

Comment 18

[Joshua Xia]

reassign to me

Comment 19

[Craig]

I'm using Win98 and I almost never turn Java on at all, but the same applies
here too. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

I've been using Mozilla for a couple of days, and memory use is astronomical:
WinTop says:
Allocated memory 18984K/146200K (code/data)
In memory 10172K/97224K
In use 8588K/66528K

This is totally off the planet. Mozilla has to be shut down every couple of days
to prevent it simply using up all available RAM. Someone really, desperately
needs to do something about the general problem, not just about Java.

Comment 20

[Manoj]

Any updates on this issue. I am currently using Phoenix 0.5 <Mozilla/5.0
(Windows; U; Windows NT 5.2; en-US; rv:1.4a) Gecko/20030314 Phoenix/0.5> and I
hit this issue everyday. 

OS: Windows Server 2003

Though Phoenix is my default browser, I have to switch back to IE for browsing
after it's memory use is up to 60-70MB (and this is both working set size and
Mem Usage - actual memory allocated for the process). When I minimize all open
Phoenix windows, the memory allocated drops drastically but then slowly bumps up
till its close to the Working Set size again. 

Why isn't Mozilla/Phoenix releasing the memory after I've closed all but one tabs.

Comment 21

[Boris Zbarsky [:bzbarsky]]

See comment 13 (which you surely read, along with the rest of this bug, before
commentin!)

Comment 22

[Joshua Xia]

*** This bug has been marked as a duplicate of 198647 ***

Comment 23

[Boris Zbarsky [:bzbarsky]]

Reopening.  This is NOT about a leak on shutdown like bug 198647.  This is about
a leak in the process of browsing.  Totally different.

Comment 24

[Thomas Brown]

Can't give version number as Help->About is broken in this build, but it's
approximately 1.5.0 build ID 2003091604

Here is a reproducable test case on a Pentium III with 192 MB RAM and Windows XP
SP1:

Before test:  Mem Usage=38840K, VM Size=28076K

Load a LARGE .jpg file such as:
http://www.spaceimaging.com/gallery/spacepics/DIA_SI_09_05_03.jpg

The browser will struggle to load the image and now your memory usage is as
follows (as your hard disk cries for mercy):

After test:  Mem Usage: 136029K, VM Size=387283K (!)

I should also note that closing that tab or moving to another web page will NOT
release the memory--only closing the browser will do that.

There are other times that VM usage goes through the roof (i.e. when viewing
Adobe Acrobat images with the browser plugin), but they are more subtle than in
this example.

See bug ID 158317 for more examples; perhaps either this one or that one should
be duped?

Comment 25

[Joshua Xia]

->kyle

Comment 26

[Kyle Yuan]

*** Bug 156994 has been marked as a duplicate of this bug. ***

Comment 27

[Peter Weilbacher]

I am not sure why bug 156994 was just duped to this one. Bug 156994 was clearly
about not releasing the java_vm memory after leaving Java related pages. This
one is clearly about something different, as bzbarsky said in #23

> This is about a leak in the process of browsing.

which does not apply to 156994. And this one is Win2000 specific, too (AFAICS),
while I reported 156994 under Linux.

Comment 28

[Kyle Yuan]

what bz said in comment 23 is against comment 22. 

please read comment 7 which complains that java doesn't free memory even if it's
not currently used.

In this bug, you might read some misleading comments about memory leak which
actually should belong to bug 130157 (comment 13)

changing os to all.

Comment 29

[Peter Weilbacher]

Yes, you are right. But to me it seems that it is not really well defined what
this bug is really about. And the title does not reflect that this is about Java.

Well, I don't really care if/where the bug I reported is duped to, but the
duplication should be very clear before doing so. Duped or not I guess there
will not be any progress soon in getting the Java VM to unload when not being
used...

Comment 30

[Kyle Yuan]

Peter, agree with you, the summary does not match to the bug perfectly. Yes,
duped bug doesn't mean any progress, it just makes people's bug list shorter and
makes other bug in that list get better cares.

bz, any particular reasons to keep 156994 opened?

Comment 31

[Boris Zbarsky [:bzbarsky]]

Not as long as there is good reason to think the two bugs are the same (perhaps
a comment in that bug with the reason when dupping would be in order).

Comment 32

[Asa Dotzler [:asa]]

*** Bug 168498 has been marked as a duplicate of this bug. ***

Comment 33

[Alexey Spiridonov]

I believe 156994 should be kept open because it asks for a specific thing: to
kill off the java plug-in when it is not in use. 

156994 is a much bigger deal on Linux than on Windows because every JVM I have
seen has a virtual footprint of 200+ MB, and actively drools over at least 20-50M. 

This is a huge drag on "low memory" systems, ones with 128 or 256 MB of RAM. I
mean, do you wants to wait for 200 megs of useless RAM to get swapped out before
your system becomes snappy? And only because a page you visited had a frivolous
Java applet? 

This is why I keep Java off. It's quite inconvenient sometimes; certainly not
friendly to novice users.

Comment 34

[Pete Zha]

mass reassign to Alfred

Comment 35

[Rolf Leggewie]

What kind of QA is wanted on this bug?

If this bug is about Java, the title still does not reflect it.  It is unclear what this bug is about and as it gets larger things are not going to improve.  Maybe close it and reopen one or more new "one issue, one report", clear and concise reports?

Comment 36

[Wayne Mery (:wsmwk)]

bz, in the context of your comment 23 "This is about a leak in the process of browsing", is this bug still of any value to get a solution given the STR, or a dupe of a more active java bug?

Comment 37

[Cees T.]

Attachment: Compared 1 IE7 window, 5 Firefox windows. 30 pages per browser.

Trying to upload this in Firefox was too difficult due to the explorer.exe filepicker (and explorer.exe itself) not responding to me.

Firefox has been running since 13:57:56   21-3-2008
IE7 has been running since 9:55:09   20-3-2008

With nightly hibernations.

Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

Comment 38

[Cees T.]

Attachment: Jittery Firefox graph, while IE7 remains constant (how come IE7's private bytes don't count as its working set?)

Comment 39

[Cees T.]

Attachment: Possible insight into the CPU usage. (I'm sure there is a 3b4 symbol set out there.)

Comment 40

[Marco Castelluccio [:marco]]

This bug should be fixed with newer versions of Firefox. Can we mark it as RESOLVED WORKSFORME?

Comment 41

[Worcester12345]

(In reply to Marco Castelluccio from comment #40)
> This bug should be fixed with newer versions of Firefox. Can we mark it as
> RESOLVED WORKSFORME?

Should be, or is fixed? See tests in comment 1 and comment 7 and let us know.

Comment 42

[Marco Castelluccio [:marco]]

I can't do the tests now, but probably these are no longer valid as the sites are different from what they were 9 years ago.
Should be fixed for the MemShrink's improvements, but I'm unsure, this is why I added it to [MemShrink] and not closed it.

Comment 43

[Nicholas Nethercote [inactive]]

I'm going to close this.  It's old, there's no patch, and we have lots of MemShrink bugs for similar kinds of things (e.g. bug 668809)... this bug isn't going to lead to any useful changes.