653013 - GC: Invent a better traversal API for the cycle collector and JS_DumpHeap

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The current API, via JS_TraceChildren, is pretty slow and crufty. We should come up with something that fits in well with the cycle collector, since it's the most important client.

This relates to bug 651445, I think.

Comment 1

[Andrew McCreight [:mccr8] (PTO until 12-2)]

One possible approach here would be to do as much JS traversal as possible inside the JS engine, to avoid CC->XPConnect->JS trips for every little step in the graph.  The CC data structure shouldn't need to expose the JS engine to random browserness.

Comment 2

[Andrew McCreight [:mccr8] (PTO until 12-2)]

I've been thinking a little about how to work towards fast CC traversal of the JS heap.  I think we can work towards this in a few stages:

1. Split up the existing CC graph into one for JS and one for non-JS.  This would have the minor advantage that we wouldn't need to unroot or unlink the JS objects.  The existing callbacks would split on langid to decide which graph to put a node into.

2. Add specialized callbacks for JS roots/children to avoid branching on langid, because mostly this can be statically determined.

The idea is that with a separate JS-only subgraph we can write a separate specialized traversal codepath.  Maybe from there we can move more of the logic into XPConnect, or even the JS engine.

Comment 3

[Andrew McCreight [:mccr8] (PTO until 12-2)]

If we can move traversal of the JS heap entirely into the JS engine, then we may not need to represent the JS heap explicitly in the cycle collector graph.  We may have to abuse mark bits or something to track traversal.  Well, or just use a hash table of some sort.

Comment 4

[(dormant account)]

Andrew, can you snappy-prioritize this?

Comment 5

[Andrew McCreight [:mccr8] (PTO until 12-2)]

Assigning it P2.  We spend a lot of time traversing JS in the CC, but on the other hand we'll have to reassess how much of a problem is after Smaug's graph pruning stuff lands.

Comment 6

[Jon Coppeard (:jonco)]

Andrew, is this bug still relevant?

I know we have JS_TraceShapeCycleCollectorChildren to skip tracing stuff the cycle collector doesn't care about, but is there more we can do here?

Comment 7

[Andrew McCreight [:mccr8] (PTO until 12-2)]

Olli's CC work did help reduce the pauses by quite a lot, but traversing JS is still a large amount of time when we're cleaning up a page after it is closed.

I have implemented some of the CC work I suggested in comment 2, by getting rid of the language generalization that was never used. The traversing code for JS stuff is now specialized, but we don't take much advantage of it. I have written code a few times to split the CC graph up into JS and non-JS, but I never landed it because it didn't provide any particular benefit.

It would be nice if we sped JS traversal somehow, but this bug is quite old and vague so I think it is okay to close it.