With bug 730753, we force a CC after every GC. We could take a more nuanced approach by dumping all C++ objects held by JS into the purple buffer after a GC, then use our normal CC heuristics to decide when to run a CC. This might allow us to not always run the CC after a GC, while still handling cases like bug 730753 which allocate an obscene amount of garbage cycles (it would actually be better in that case, because it would work even with compartmental GCs). I'm not sure whether we can actually get a list of all such C++ objects. XPC has to store all C++ -> JS references so the GC will work, but I don't think there's any requirement the other way around. It looks like some of XPCJSRuntime::AddXPConnectRoots works by adding the JS objects, then just relying on the fact that you'll eventually end up at JS -> C++ edges by tracing through JS. Another problem is that not all C++ things held alive by JS are necessarily XPCOM objects. If they aren't, we can't add them to the purple buffer. We could either ignore them, and hope that they never matter enough, or track them somehow separately (for instance, keep a separate count of non-XPCOM things we saw at the last CC, and treat them as increasing the size of the purple buffer, event though we never examine them). These may be insurmountable problems, but it would be nice if we could have a heuristic for the GC triggering CC that is somewhere in between never doing it and always doing it.

Maybe a simpler thing would just be to iterate over all XPConnect roots, and count the number for which CanSkip fails, and treat that count as being part of the purple buffer count when deciding to trigger a CC.