Perfherder has detected a awsy performance regression from push fc2b3d6448bcc3575fffb1abc923e7e703aeef54. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Set release status flags based on info from the regressing bug 1749380

I suspect we end up with a different configuration of render targets in the target pool, so I'm not particularly concerned about this. However, I'll investigate this week to confirm if (and why) that's what is happening here.

I've spent some time investigating this (relevant try runs from before and after are https://treeherder.mozilla.org/jobs?repo=try&revision=7de2e449300646a62b4eddbe686cfda8b9e84809&selectedTaskRun=Txa2S72HSzmh6ITOqxONaQ.0 and https://treeherder.mozilla.org/jobs?repo=try&revision=709672bb612bfc85e2f073dd6f439bcbe7d42e80&selectedTaskRun=BTObWP9YT2K9NOPwmXedgA.0).

From the artifacts in those runs, we can see that the WR render target pool sizes are different. The reason this shows up in heap-unclassified is because they correspond to GPU driver allocations that we can't annotate.

I've then run the AWSY tests locally with gfx.webrender.debug.render-targets enabled. In each case, I can see that the render target pool is different, but is also expected (the patch in question has effects on the size / scale of render target allocations, which will affect the number and size of currently allocated targets in the render target pool).

The sub-tests which report different values are the tabs closed and tabs closed + 30s variants. We retain targets in the render target pool for some time to avoid jank when allocating and freeing large targets.

I confirmed locally that the render target pool is being correctly garbage collected after mouse moving on the page (so that WR doesn't think the targets have been used recently).

So, it seems reasonable to close this as expected?