649456 - duplicate edges are added to cycle collector graph

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

Attachment: count duplicate edges, copy nodes containing dup edges

Edges are added multiple times to the cycle collector graph.  We should be able to easily eliminate some of these duplicates, which would improve cycle collector speed and memory usage.

The attached script will analyze a standard cycle collector edge log, and produce a version of the edge log with only nodes containing duplicate edges, with the duplicates annotated.

Comment 1

[Andrew McCreight [:mccr8]]

Attachment: count duplicate edges, copy nodes containing dup edges

Previous version wasn't counting the number of duplicates saved by examining previous edge.

Some numbers: on a JS heavy CC heap, 3544 duplicate edges, 1819 of these same as previous edge.  on a less JS heavy heap, 479 duplicate edges, with 350 of these same as prev edge.

Not a huge number, but it should be easy to eliminate some of these.

Comment 2

[Andrew McCreight [:mccr8]]

I hacked up an implementation of this.  I think it makes sense to use one cache per type of child (XPCOM, native, script) as I imagine objects are not going to be more than one time.  My implementation just stores the previous edge of a given type for the current node.  On a quick test run with 3 CCs, this eliminated about 1.2% of edges.  There were around 460k edges in each CC graph.

Per peterv's suggestion, pruned edges are logged, but not added to the CC graph (but the internal count is taken into account).  With my new logging format it looks like this in the log:

0x10487f650 [rc=2] nsXULTemplateBuilder
> 0x10487ff70 mDataSource
> 0x10487ff70 {prev XPCOM dup} mDB
> 0x10487ff70 {prev XPCOM dup} mCompDB
> 0x121046fe0 mRoot

Comment 3

[Andrew McCreight [:mccr8]]

Marking this as WONTFIX, as there really are not enough duplicate edges to make it worthwhile.