I think this is needed to avoid getting timeouts on Mochitest-BC. One thing I've tried out which seems to work fairly well in local testing is to scale the slice budget by the % amount we've fallen behind our target for scheduling slices. For example, we try to run 10ms slices every 32ms. If we end up spending 64ms between two slices instead, then we'll budget 20ms of ICC work. That way we're doing a roughly constant amount of CC work per unit of wall clock time.

Well, with that, it is only failing 50% of the time, and both failures are on a single test, so that's an improvement.

If we exceed the desired length of time between ICC slices, proportionally scale up the slice budget to try to ensure a constant amount of collection work is done per unit of time, even when the browser is under heavy load. As part of this, track the time the last slice from the current ICC ended. https://tbpl.mozilla.org/?tree=Try&rev=1e1b69edc562

Earlier, I had some kind of threshold for the scaling factor, and if you fell below that threshold, you'd just do the regular slice time, but that seems overly complex at this point. Maybe later it will be worthwhile doing that kind of tuning.

Comment on attachment 8385735 [details] [diff] [review] Scale ICC budget by time between slices. r=smaug Rename ICCSliceTime to CollectCycleCollectionSlice or some such and call nsCycleCollector_collectSlice inside that method using the value you get using the algorithm in this patch? I think the patch as such is a bit too confusing - at least to understand at 3:30am.

Comment on attachment 8386881 [details] [diff] [review] Scale ICC budget by time between slices. >+ // Only run a limited slice if we're within the max running time. >+ if (TimeBetween(gCCStats.mBeginTime, now) < kMaxICCDuration) { >+ float sliceMultiplier = TimeBetween(gCCStats.mEndSliceTime, now) / kICCIntersliceDelay; Can you add some max(sliceMultiplier, 1) thing here.

Added max. Thanks for all of your feedback. https://hg.mozilla.org/integration/mozilla-inbound/rev/de9636679191