Open Bug 653013 Opened 9 years ago Updated 2 years ago
GC: Invent a better traversal API for the cycle collector and JS
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.
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.
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.
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.
Andrew, can you snappy-prioritize this?
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.
Whiteboard: [Snappy] → [Snappy:P2]
You need to log in before you can comment on or make changes to this bug.