Memory usage gradually increases on www.sina.com.cn

RESOLVED FIXED

Status

()

Core
General
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: njn, Assigned: gwagner)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

(Reporter)

Description

6 years ago
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)

Updated

6 years ago
Blocks: 659856
Whiteboard: [MemShrink:P2]
(Reporter)

Updated

6 years ago
Duplicate of this bug: 652801
(Reporter)

Comment 2

6 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.
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

6 years ago
Thanks for the quick confirmation!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 5

6 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

6 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

6 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

6 years ago
Depends on: 656120
(Reporter)

Updated

5 years ago
Assignee: nobody → anygregor
You need to log in before you can comment on or make changes to this bug.