Closed Bug 1541819 Opened 1 year ago Closed 1 year ago

Track allocation made while attaching a target to a tab

Categories

(DevTools :: Framework, defect)

defect
Not set

Tracking

(firefox68 fixed)

RESOLVED FIXED
Firefox 68
Tracking Status
firefox68 --- fixed

People

(Reporter: ochameau, Assigned: ochameau)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

While working on bug 1539518, I realized there was a leak in BrowserTabList (bug 1540693).
I would like to land a very first attempt at tracking memory allocations for a simple operation: create a target for a tab.

Something as simple as that:

  const target = await TargetFactory.forTab(tab);
  await target.attach();
  await target.destroy();

Because of an issue within BrowserTabList, we are leaking the RootActor and classes from actors/webbrowser.js like BrowserTabList after the target is destroyed.
So, it means that we are leaking a few objects everytime we close a toolbox and that leak is in the parent process.

The goal here is to have a quite simple test script, which will only record the number of objects that are being created and still allocated during this simple test script. And prove that if we land the BrowserTabList fix, this record will be reduced. And also see if the record is stable over time and only changes when there is a fix or a real regression.

Later on, as part of bug 1540693, I'm planning to augment this test in order to provide more information, like the allocation sites. So that we can debug regressions if one happens.

Here is two try runs:

  • One with the test recording target creation allocation:
    The test reports: 1391, 1428, 1391, 1391, 1391, 1428 allocations.
  • Another one with the same test + bug 1540693 fixing the BrowserTabList leak
    The test reports: 1363, 1363, 1363, 1362, 1400, 1363 allocations

Two conclusions here:

  • The test result is not stable on try, it isn't 100% stable locally, but more stable than on try. (It looks more stable with the leak being fixed?!)
  • Fixing the leak clearly reduce the allocation report!

So I think this is valuable enough to proceed with this.
First land the test, let it run a couple of days and then land the leak fix and see how looks the graph.

Using official build flag was breaking tests on try as the builds
are done with the official build flag turned on.
Convert this module into a "supports" file, like other test-only files.
And also introduce a test for this module. It helps as we have to have
a browser.ini file in order to reference allocation-tracker.js,
and you can't have a browser.ini without any test in it.

Depends on D26105

This records on Talos the number of allocated objects after creating, attaching and destroying a Tab Target.

Depends on D26107

Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cf5247b84251
Allow tracking memory only for one global or only DevTools ones. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/0fc7897656f9
Allow the loader to load modules in a distinct system compartment. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/251858ceaf0c
Ship allocation-tracker when running tests and test it. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/d6b5206811a3
Expose the number of still-allocated objects via the allocation tracker. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/647ed1af3d0d
Record allocations of Target class. r=jdescottes
Depends on: 1544699
You need to log in before you can comment on or make changes to this bug.