This is quite an interesting behavior. So here a summary of my investigation from yesterday... So I picked the top-most regression data, which is about `Images`, and happening across platforms with a ~24% increase: ``` 25% Images linux1804-64-shippable-qr 4,556,804.97 -> 5,694,325.92 24% Images windows10-64-shippable-qr 6,150,925.17 -> 7,630,074.22 24% Images macosx1014-64-shippable-qr 5,290,836.76 -> 6,561,703.93 23% Images linux1804-64-shippable 4,512,409.84 -> 5,532,798.34 ``` When checking the results directly on [https://arewefastyet.com](https://arewefastyet.com/mac/memory/Images?numDays=60) they directly apply to the very first graph. It clearly indicates the increase on Dec 18th. Also other graphs show the regression but interestingly aren't getting reported? With some help from Andrew I had a look at graph 3 and 4. What's interesting here is that for graph 4 we seem to miss to garbage collect images, or AWSY records the memory usage before the next GC runs. With a forced GC (graph 3) everything is still fine. Diffing two memory reports for `After tabs open [+30s]` (one from before my landing, and one after) I can see a lot of images from tp5 pages, which were loaded in all the various tabs, that are not marked as `unlocked`. Means the next GC will not free those up. And as such more memory is used. In the above case we speak about 35MB. As next step I continued on the results from comment 3, and identified [bd98eeb06846](https://hg.mozilla.org/integration/autoland/rev/bd98eeb06846) as the causing changeset. Here we are going to add some events (specifically `click`, `dblclick`, and `unload`) that should cause the `MarionetteEventsActor` to be created. Based on when those fire we want to set some internal state to track mouse clicks/double clicks. When inspecting the AWSY tests I cannot see anything around mouse clicks. What it basically does is opening tabs, and loading various pages from the tp5 pageset. That's all. But that means that the one and only event that should have an effect here is `unload`. To check what's happening when we don't specify it when registering the actor but using `addEventListener` within the actor's child, I submitted a new [try build](https://treeherder.mozilla.org/jobs?repo=try&revision=11e4dd86e8e37941e5f71402a008cf2f471ab424), and interestingly the results are looking promising. All the values seem to go back to their original values: https://treeherder.mozilla.org/perfherder/compare?originalProject=mozilla-central&newProject=try&newRevision=11e4dd86e8e37941e5f71402a008cf2f471ab424&framework=4&selectedTimeRange=172800 So I assume there is something strange going on for JSWindowActors with a `unload` event being registered. Note that we also have `beforeunload` and `pagehide` registered, which already cause an actor pair to be created. So that the `unload` event should basically be a no-op. But instead is causes various huge memory regressions. Nika, Olli, and Kris, does one of you have an idea why this is happening? Could this be a bug in our JSWindowActor implementation?
Bug 1683841 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This is quite an interesting behavior. So here a summary of my investigation from yesterday... So I picked the top-most regression data, which is about `Images`, and happening across platforms with a ~24% increase: ``` 25% Images linux1804-64-shippable-qr 4,556,804.97 -> 5,694,325.92 24% Images windows10-64-shippable-qr 6,150,925.17 -> 7,630,074.22 24% Images macosx1014-64-shippable-qr 5,290,836.76 -> 6,561,703.93 23% Images linux1804-64-shippable 4,512,409.84 -> 5,532,798.34 ``` When checking the results directly on [https://arewefastyet.com](https://arewefastyet.com/mac/memory/Images?numDays=60) they directly apply to the very first graph. It clearly indicates the increase on Dec 18th. Also other graphs show the regression but interestingly aren't getting reported? With some help from Andrew I had a look at graph 3 and 4. What's interesting here is that for graph 4 we seem to miss to garbage collect images, or AWSY records the memory usage before the next GC runs. With a forced GC (graph 3) everything is still fine. Diffing two memory reports for `After tabs open [+30s]` (one from before my landing, and one after) I can see a lot of images from tp5 pages, which were loaded in all the various tabs, that are not marked as `unlocked`. Means the next GC will not free those up. And as such more memory is used. In the above case we speak about 35MB. As next step I continued on the results from comment 3, and identified [bd98eeb06846](https://hg.mozilla.org/integration/autoland/rev/bd98eeb06846) as the causing changeset. Here we are going to add some events (specifically `click`, `dblclick`, and `unload`) that should cause the `MarionetteEventsActor` to be created. Based on when those fire we want to set some internal state to track mouse clicks/double clicks. When inspecting the AWSY tests I cannot see anything around mouse clicks. What it basically does is opening tabs, and loading various pages from the tp5 pageset. That's all. But that means that the one and only event that should have an effect here is `unload`. To check what's happening when we don't specify it when registering the actor but using `addEventListener` within the actor's child, I submitted a new [try build](https://treeherder.mozilla.org/jobs?repo=try&revision=11e4dd86e8e37941e5f71402a008cf2f471ab424), and interestingly the results are looking promising. All the values seem to go back to their original values: https://treeherder.mozilla.org/perfherder/compare?originalProject=mozilla-central&newProject=try&newRevision=11e4dd86e8e37941e5f71402a008cf2f471ab424&framework=4&selectedTimeRange=172800 So I assume there is something strange going on for JSWindowActors with a `unload` event being registered. Note that we also have `beforeunload` and `pagehide` registered, which already cause an actor pair to be created. So that the `unload` event should basically be a no-op. But instead is causes various huge memory regressions. Nika, Olli, and Kris, does one of you have an idea why this is happening? Could this be a bug in our JSWindowActor implementation?