[Meta] After starting Firefox and running various asynchronous initialization steps cycle collection graph should stay empty if browser is idle

RESOLVED INACTIVE

Status

()

Core
General
RESOLVED INACTIVE
6 years ago
3 days ago

People

(Reporter: smaug, Assigned: smaug)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

6 years ago
We should be able to keep the graph empty if CanSkip* methods are very effective
and nothing is creating new garbage.
Things to look at:
- XBL
- XUL protos
- ObserverService
Blocks: 698919
This sounds like a great goal.  Concrete, and it should have a positive overall impact!
(Assignee)

Updated

6 years ago
Version: 12 Branch → Trunk
We should come up with a set of pages we want to investigate first.  At first guess, I'd imagine that web apps like Gmail and Facebook will be active even when the user is idle.  Should we exclude them from consideration?
(Assignee)

Comment 3

6 years ago
At first step I want to just open 1 about:blank tab in Firefox and have empty CC graph when
CC is called. This mean that various things which still add script objects to the graph
need to be optimized out.
That does sound like a good starting point.
Blocks: 716598
No longer blocks: 698919
Depends on: 735342
Created attachment 606895 [details]
CC log with my latest set of patches
Created attachment 606896 [details] [diff] [review]
CC log with my latest set of patches

I think I didn't actually finish a full recompile with that previous log.  This one looks much better.  Something appears to manage to swoop up the bulk of the XUL prototype nodes.  I'm not sure what that's about.
Attachment #606895 - Attachment is obsolete: true
There are 626 nodes in the graph.  83 nodes by themselves.  64 nodes in pairs, mostly involving nsXPCWrappedJS.  Most of the rest looks like things that are being held alive by the observer service, though there are a few other weird cases, like a global_for_XPCJSContextStack_SafeJSContext.
Depends on: 737060
Depends on: 735550, 736763
Depends on: 737075
Depends on: 712735
bug 736563 clears up a few small blobs of about:blank from the graph.
Depends on: 736563
With all the patches in the dependent bugs applied, I'm seeing a CC graph with 494 nodes, with my Gmail + mozilla wiki + error console.

This is the breakdown by size of blob:

1=180(180), 2=49(98), 3=8(24), 4=3(12), 6=1(6), 7=1(7), 8=2(16), 10=2(20), 14=1(14), 16=1(16), 46=1(46), 55=1(55),

The format is blobsize=numOfBlogs(total number of nodes in blobs of that size).

The two largest chunks are the JS Safe Context and a big chunk of script that an nsXULPrototypeNode holds onto.
Created attachment 610278 [details]
the full CC graph with these patches
Attachment #606896 - Attachment is obsolete: true
Attachment #610278 - Attachment is patch: false
Attachment #610278 - Attachment mime type: text/plain → application/pdf
Depends on: 740185
There's still some room for improvement of nsXULPrototypeNodes.  In my regular browsing session, there are about 4000 nodes in the graph, and around 1900 of these are in a single blob of JS being traced from an nsXULPrototypeNode.  We could probably add black JS tracing for these somehow.  There are also two other blobs with a hundred or so JS nodes in them that also look like that.
Depends on: 785493
Depends on: 829784

Comment 12

3 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.