1306086 - Add assertions checking for excessive calls to TraceChildren during cycle collection

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Andrew McCreight [:mccr8]]

As seen in bug 1301301, adding a new GC kind can cause cycle collection to get very slow if the new GC thing gets repeatedly traced by different objects. We should add some regression testing to make sure we aren't spending too much time on these objects. My current idea for checking this is to track the ratio of Traversed GC things to calls to TraceChildren. I have spun this into a separate patch because selecting a ratio is tricky because you want it to fail in bad cases but not fail in good cases. I should also add debugging logging that prints out the ration to make it easier to figure out what is going on when the threshold is exceeded.

Comment 1

[Andrew McCreight [:mccr8]]

I retriggered some of the original tests that caused issues, but they didn't go orange. I'll try some more.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=088f123387a4

Comment 2

[Andrew McCreight [:mccr8]]

This attempt to retrigger did not find any either:
  https://treeherder.mozilla.org/#/jobs?repo=try&revision=cd092dfb6bbb
I did managed to trigger the failures on the weird video test, but my debugging output does not appear in the log.

Comment 3

[Andrew McCreight [:mccr8]]

By my count, in the last week there are 27 failures in bc5, 11 in e10s bc2, 9 in e10s bc4, 6 in bc4, 4 in bc6, 1 in bc1 and e10s bc3.

Comment 4

[Andrew McCreight [:mccr8]]

Unfortunately, I don't think this is fixable. The ratio seems like it is all over the place.