One issue is that V8 and Blink's GCs use the same IdleTaskRunner as rIC, and ideally we want them to be able to run quickly when the tab goes into the background to free up memory. Is it worth having an internal and external idle task runner so we can throttle one but not the other?

Re #1: I also like this idea a lot from attribution perspective — splitting GC out will help us understand real rIC performance in the world. 

Since we've now limited idle periods to cycle once every 50ms in background tabs, it feels like we probably don't need to throttle more here than that? I also feel that we shouldn't split idle work to different classes since it feels simpler if all idle work should follows the same contract.

It seems strange to me that rIC fires more frequently than setTimeout(0) in background tabs, but maybe it won't actually cause any real world problems?

That's my assumption too.

I looked at UMA briefly and for whatever reason we still run a few idle tasks after a tab has been in the background for more than five minutes:

https://uma.googleplex.com/p/chrome/histograms/?endDate=20170803&dayCount=1&histograms=RendererScheduler.TaskDurationPerQueueType2.Background%2CRendererScheduler.TaskDurationPerQueueType2.Background.AfterFifthMinute&fixupData=true&showMax=true&filters=platform%2Ceq%2CW%2Cchannel%2Ceq%2C2%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

I'm not sure what would cause that.