Closed Bug 123191 Opened 23 years ago Closed 13 years ago

Mozilla doesn't release memory used to render prior pages


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



(Not tracked)



(Reporter: DomIncollingo, Assigned: alfred.peng)



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


(6 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
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  (This site does not
require much memory to render.)
3.Mozilla memory utilization is at about 18 MB.
4.Navigate to
5.Navigate to
6.Navigate to
7.Navigate to
8.Navigate to
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
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, 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
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, 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
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                 17.6MB                      18.9MB     19.7MB              20.6MB              25.2MB  22.4MB                 20.6MB
(Usage stayed at about 20.x MB as long as I remained at

Java Enabled                 18.1MB                  36.1MB     37.4MB              38.7MB              44.1MB  39.8MB                 38.4MB
(Usage stayed at about 38.x MB as long as I remained at
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 and then never shut it down (this behavior is by
design).  Task Manager is lumping the java plugin's memory use in with
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
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

*** This bug has been marked as a duplicate of 198647 ***
Closed: 21 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.
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

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

Load a LARGE .jpg file such as:

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?
Assignee: joshua.xia → kyle.yuan
*** 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
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

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.
Closed: 21 years ago13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.