Closed Bug 123191 Opened 21 years ago Closed 12 years ago

Mozilla doesn't release memory used to render prior pages

Categories

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

x86
All
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: DomIncollingo, Assigned: alfred.peng)

References

Details

(Keywords: memory-footprint, qawanted, Whiteboard: [CPU usage][MemShrink])

Attachments

(6 files)

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.
Dom, what's your memory cache size set to?  Do you have the java plugin?  Is the
number for mozilla including the JVM size?
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/.
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?
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)
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...
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.
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.
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Keywords: qawanted
Whiteboard: Clear explanation of problem needed
Component: Browser-General → Layout
.
Assignee: asa → attinasi
QA Contact: doron → petersen
sending to Plug-ins, which appears appropriate for original report.
Assignee: attinasi → beppe
Component: Layout → Plug-ins
QA Contact: petersen → shrir
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
Assignee: beppe → av
Priority: -- → P3
Whiteboard: Clear explanation of problem needed → [CPU usage]
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?
Assignee: av → joe.chou
Component: Plug-ins → OJI
QA Contact: shrir → pmac
QA Contact: pmac → petersen
reassign to me
Assignee: joe.chou → joshua.xia
Keywords: footprint
Whiteboard: [CPU usage] → [CPU usage], redesign?
Whiteboard: [CPU usage], redesign? → [CPU usage]
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.
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.
See comment 13 (which you surely read, along with the rest of this bug, before
commentin!)

*** This bug has been marked as a duplicate of 198647 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Reopening.  This is NOT about a leak on shutdown like bug 198647.  This is about
a leak in the process of browsing.  Totally different.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: 203448
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?
->kyle
Assignee: joshua.xia → kyle.yuan
Status: REOPENED → NEW
*** Bug 156994 has been marked as a duplicate of this bug. ***
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.
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.
OS: Windows 2000 → All
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...
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?
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).
Blocks: 215491
*** Bug 168498 has been marked as a duplicate of this bug. ***
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.
No longer blocks: 215491
Assignee: yuanyi21 → pete.zha
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
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?
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?
QA Contact: chrispetersen → java.oji
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
Product: Core → Core Graveyard
This bug should be fixed with newer versions of Firefox. Can we mark it as RESOLVED WORKSFORME?
Whiteboard: [CPU usage] → [CPU usage][MemShrink]
(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.
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.
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.
Status: NEW → RESOLVED
Closed: 20 years ago12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.