Closed
Bug 666101
Opened 13 years ago
Closed 13 years ago
Memory usage gradually increases on www.sina.com.cn
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: n.nethercote, Assigned: gwagner)
References
Details
(Whiteboard: [MemShrink:P2])
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.
Reporter | ||
Comment 2•13 years ago
|
||
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•13 years ago
|
||
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.
Reporter | ||
Comment 4•13 years ago
|
||
Thanks for the quick confirmation!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 5•13 years ago
|
||
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.
Assignee | ||
Comment 6•13 years ago
|
||
(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.
Reporter | ||
Comment 7•13 years ago
|
||
I see. Sounds like fragmentation could be quite bad, then. I am working right now on reporting more stats about the heap.
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → anygregor
You need to log in
before you can comment on or make changes to this bug.
Description
•