108475 - Footprint: Quick Launch (-turbo) retains swap space after closing last window

Status: VERIFIED FIXED

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Description

[Damian Yerrick]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5+) Gecko/20011023
BuildID:    2001102309

Many programs allocate memory from the C heap.  When the C heap
expands beyond the application's heap, the C library calls such
functions as sbrk() to expand the application's heap.  However,
when a program free()s a lot of memory, the C library never shrinks
the application's heap, and even though the OS's memory manager
swaps out the unused pages, they still contribute to reduced I/O
performance by expanding and fragmenting the swap file.

Mozilla's Quick Launch feature retains large chunks of swapped-out
memory when not in use.

Reproducible: Always
Steps to Reproduce:
1. Enable Quick Launch and restart the computer.
2. In Wintop (part of Kernel Toys), observe Mozilla's memory stats.
3. Open several windows on sites with large pages (such as /., k5, etc).
4. Close all Mozilla windows.
5. In Wintop (part of Kernel Toys), observe Mozilla's memory stats.

Actual Results:  
Wintop reports that Mozilla.exe is still holding on to a significant
amount of allocated memory.

Expected Results:  
Mozilla should act like IE, freeing most of its allocated memory once
the user closes the last window.

Workaround: don't use Quick Launch.

Another workaround:
1. From the Mozilla tray icon's menu, choose Exit Mozilla.
2. Restart Mozilla from the Start menu.
3. Close the Navigator window.

Proper Fix(TM): Quit and quietly restart Mozilla once the
user closes the last window.


Sorry for reporting this bug against such an old build, but most
builds to which Mozillazine has linked recently have had dataloss,
prominent crash, or other blocker bugs.

Comment 1

[sairuh (rarely reading bugmail)]

->quick launch

Comment 2

[Damian Yerrick]

MozillaZine has just reviewed a more recent build (2001110603 for win32)
and I have installed that build.  I'll report some hard data as to
Mozilla's footprint after closing the last window.  Readings of Wintop's
"allocated memory" statistic follow:

Start Mozilla from Explorer, placing the seamonkey in the systray: 15 MB
Open several tabs in several browser windows, plus one each of Mail,
Composer, and Chatzilla: 38 MB
Close all windows: 35 MB
Close Mozilla from the systray, and restart Mozilla: back to 15 MB

This could potentially pile up for users who run Moz on Win2K and WinXP
machines (and even clean Win98 and WinME machines) that have sufficiently
long uptimes, especially as the rest of Mozilla becomes more stable and
has more time to fragment its heap.

Comment 3

[Bill Law]

We should look at issuing calls to force release of resources back to the OS at 
strategic points (e.g., when the last window closes).  Not sure how much of the 
space observed here is leaked, though.

Comment 4

[Jan Derk]

I suspect that (under Windows) Mozilla is not leaking resources at all, but that
Windows is not reclaiming resources/memory. I may be oversimplefying but
quicklaunch seems to just hide windows. Instead it might be a good idea to
minimize all windows before hiding.

Although, like Bill says, telling the system directly to reclaim resources
should be the final solution.

Test case 1:
1) Load a few large pages in Mozilla. Say Mozilla is at 50MB usage.
2) Now close Mozilla while in quick launch mode. It will still seem to use 50MB.

Test case 2:
1. Load a few large pages. Say Mozilla is at 50MB usage.
2. Minimize all Mozilla windows. Mozilla now seems to use less than 5MB on my
W2K system.

Comment 5

[Jan Derk]

I took a look at the MSDN and the SetProcessWorkingSetSize() method could solve
the hanging resource problem.  Here's a quote from the Winapi manual:

"If both dwMinimumWorkingSetSize and dwMaximumWorkingSetSize  have the value -1,
the function temporarily trims the working set of the specified process to zero.
This essentially swaps the process out of physical RAM memory."

http://msdn.microsoft.com/library/en-us/dllproc/prothred_07l1.asp

I checked in one of my own applications a simple:

SetProcessWorkingSetSize (GetCurrentProcess(), 0xffffffff, 0xffffffff);

Statement reduced the reserved memory from 30MB to about 1MB. Seems just what
one needs when closing Mozilla under QuickLaunch.

Unfortunately it only works on WinNT/2000 & XP.

Comment 6

[Blake Ross]

-> me

Comment 7

[Blake Ross]

Attachment: proof-of-concept patch

Comment 8

[Blake Ross]

Well, damn. It certainly seems to work.  I had results just like yours -- 30 MB 
before closing my last window and then, with this patch, 15 MB.

A pity that this only works on NT and XP, though. Is there a comparable 
function we can call for 9x?

Cc'ing law.

Comment 9

[Blake Ross]

(Oh, er, and of course I need to #ifdef XP_WIN the function call.)

Comment 10

[Damian Yerrick]

If we can't find an analogous API call to free unused memory on Windows 9x,
why not just restart Mozilla whenever a Win9x user closes the last window?

Comment 11

[Bill Law]

Blake, rather than #ifdef that code, why not move it to nsNativeAppSupportWin.cpp?

I don't think you want to issue that call if we're not in turbo mode;
nsNativeAppSupportWin::OnLastWindowClosing already is checking for that case. 

Comment 12

[Blake Ross]

Oh, good point. I will.  The patch attached does only do the call if in server
mode, though.

Will this compile on 9x or do I have to check win flavor...?  And do you want to
check this in or look for a solution that works everywhere?

Comment 13

[Bill Law]

I can't tell what that call does on Windows.  The docs say it is "unsupported"
and I don't know if that means the function doesn't exist there, or, simply does
nothing.  My experience is that we'll get a ERROR_NOT_SUPPORTED return value or
some such.

I won't get to this for a little while so you can keep the bug.

One question: What impact does this have on subsequent mozilla usage:

a. When right-clicking to get the systray icon menu (if there's a noticeable
delay, it might not be good).
b. When opening a new window.  If that's too long, then people might complain, too.

Maybe a compromise would be to do this call after some period of inactivity?

Comment 14

[Blake Ross]

Attachment: patch - moved to nsNativeAppSupportWin

Comment 15

[Blake Ross]

I don't notice any change in performance when doing either of those actions.

(Note that this restores mem usage to, for me, ~15 MB after closing the last
window.  This is exactly what it is when you first start turbo, before opening
any windows).

r=?

Comment 16

[Blake Ross]

Hmm...the checkin for bug 123729 partially fixes this -- they did this for main
windows -- but the last window closed when in turbo could conceivably be, say,
the history window.  But I don't know if we should bother keeping this call in.

Comment 17

[Blake Ross]

Marking fixed.

Comment 18

[Grace Bush]

verified on NT (N6 - mem usage dropping 50% on NT (15000k-7000k)
(less on Win2000- 25000k to 18000k) 
Mozilla on Win2000 18000k to 8000k

builds for 2/12 and 2/13

Comment 19

[Nathan Bidwell]

Should this be reopened now that bug 125100 has been fixed?  (backing out the
fix of 123729 )