Closed Bug 666101 Opened 13 years ago Closed 13 years ago

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

Categories

(Core :: General, defect)

x86
Windows 7
defect
Not set
normal

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.
Blocks: mlk-fx4
Whiteboard: [MemShrink:P2]
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.
Thanks for the quick confirmation!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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.
(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.
I see. Sounds like fragmentation could be quite bad, then. I am working right now on reporting more stats about the heap.
Depends on: 656120
Assignee: nobody → anygregor
You need to log in before you can comment on or make changes to this bug.