Last Comment Bug 666101 - Memory usage gradually increases on www.sina.com.cn
: Memory usage gradually increases on www.sina.com.cn
Status: RESOLVED FIXED
[MemShrink:P2]
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Gregor Wagner [:gwagner]
:
:
Mentors:
: 652801 (view as bug list)
Depends on: 656120
Blocks: mlk-fx4
  Show dependency treegraph
 
Reported: 2011-06-21 19:56 PDT by Nicholas Nethercote [:njn]
Modified: 2012-01-14 00:29 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Nicholas Nethercote [:njn] 2011-06-21 19:56:53 PDT
This is a spin-off from bug 640923 comment 5;  that bug has become a mess.

Steps to reproduce:
- firstly, open two tabs: www.sina.com.cn and finance.sina.com.cn/stock.
- then, when these two tabs opened completely, the memory used is 110M.
- Next, I left firefox opened without any touch.
- 25 minutes later, the memory used is 180M.
Comment 1 Nicholas Nethercote [:njn] 2011-06-21 20:09:23 PDT
*** Bug 652801 has been marked as a duplicate of this bug. ***
Comment 2 Nicholas Nethercote [:njn] 2011-06-21 20:30:22 PDT
qisheng.zhao: it's very likely that bug 656120 has fixed this problem.  Can you please try a nightly build (nightly.mozilla.org) and let us know if it has been fixed?  Thanks.
Comment 3 qisheng.zhao@gmail.com 2011-06-21 22:36:23 PDT
tested with 7.0a1 nightly 0621 version. the bug is basically fixed.
1. opened fx in safe mode
2. opened finance.sina.com.cn/stock, memory ocuppied was about 97M .
3. 20 minutes later, memory usage gradually increased to 135M.
4. two hours later, memory usage is about 132M.
Comment 4 Nicholas Nethercote [:njn] 2011-06-21 22:43:07 PDT
Thanks for the quick confirmation!
Comment 5 Nicholas Nethercote [:njn] 2011-06-23 00:10:00 PDT
I was able to reproduce the before and after behaviour -- about:memory said my "explicit" usage was 200MB vs. 140MB after a couple of hours.

The really interesting thing is that after I minimize the memory usage via about:memory, I still see a difference:  148MB vs 123MB.  The difference is still entirely due to the explicit/js/gc-heap value -- 54MB vs 26MB.

And then if I close the sina.com.cn windows and minimize memory usage again, the explicit numbers are 86MB vs 81MB, and the gc-heap numbers are 32MB vs 26MB.

It's almost as if the more frequent GCs are somehow avoiding some leaks.
Comment 6 Gregor Wagner [:gwagner] 2011-06-23 13:25:38 PDT
(In reply to comment #5)
> 
> It's almost as if the more frequent GCs are somehow avoiding some leaks.

gc-heap represents the amount of allocated/mapped chunks right?
As said before, my explanation is fragmentation. We allocate all sort of objects in there that tend to stick. Pinned strings for example can keep a whole chunk alive.

If we perform more GCs then it's less likely that these objects are placed in a new chunk.

Nick you were working on the heap traversal right? It would be good to be able to compare 2 heap snapshots from before/after. My guess is that the same amount of objects is alive but they reside in fewer chunks.
Comment 7 Nicholas Nethercote [:njn] 2011-06-23 17:24:07 PDT
I see.  Sounds like fragmentation could be quite bad, then.  I am working right now on reporting more stats about the heap.

Note You need to log in before you can comment on or make changes to this bug.