Closed Bug 749201 Opened 8 years ago Closed 6 years ago

[meta] make cycle collection faster on mobile


(Core :: XPCOM, defect)

Not set



blocking-kilimanjaro -


(Reporter: smaug, Unassigned)


(Blocks 1 open bug)


This could be just a variant of bug 698919, but it is possible that there are
some mobile specific cases we should optimize.
blocking-kilimanjaro: --- → ?
OS: Linux → All
Version: 12 Branch → Trunk
Do we have any idea what CC times are like on mobile?  My general strategy for mobile CC (like with mobile MemShrink) was to wait until somebody started complaining about it, but I haven't heard anything yet.
Hardware: x86_64 → All
Blocks: 698919
Right now there is a very small audience on mobile and larger problems that need to be addressed. That's to say, I'm not sure anyone is yet in a position to complain about this. (Aaron Train can tell you about OOM issues.)

I think we should try to be more proactive with mobile. We need a solid platform for app developers. It seems to me by the time people start complaining we may have already lost the minds of some devs. Is there a way to do some investigation on Fennec once it goes to Beta?
Well, by "somebody" I meant Mozilla people working on Mobile. :)  I guess it is difficult to think about various product quality initiatives while you are still very focused on basic features.

To investigate this, we need some way to see what the cycle collector times actually are.  On Desktop, we have the error console, in concert with the option that shows what CC times are.  I don't know if that is available on Mobile or not.  (There is also MemChaser, but that's an addon (and one that relies on the error console) so that seems less likely to work.)  If that doesn't work, then I guess we'd have to rig up some custom code to log that.  Though, is the profiler stuff that Benoit is working on probably is working on Mobile?  It should be possible to get at least some information about CC pause times from that...
I was told the (error) console messages are logged somewhere.
CC times are too high there.
Thanks for posting that.

The graph sizes seem fairly reasonable.  There's an oddly high amount of variance in CC times:

CC(T+91.6) duration: 9ms, suspected: 20, visited: 136 RCed and 36 GCed, collected: 16 RCed and 0 GCed (16 waiting for GC)
CC(T+218.5) duration: 137ms, suspected: 6, visited: 95 RCed and 36 GCed, collected: 0 RCed and 0 GCed (16 waiting for GC)

That's from two CCs in a row.  Though it looks like there was a long time between them.
No longer blocks: 698919
Blocks: 698919
Depends on: 549798
k9o- for now as there's no specific work yet defined. Please renom once CC on mobile is better understood if there are specific changes that can be made that will impact performance in relation to k9o.
blocking-kilimanjaro: ? → -
This is still an important goal, but this bug never went anywhere.
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.