Working on one of our partner's games, I'm noticing the memory footprint grow inbetween refreshes, as if something isn't being cleaned up in the platform. STR: 1: open memory tools, enable allocations 2: Go to http://tanx.playcanvas.com (or can provide local source privately) 3: Wait til your tank spawns, take a snapshot 4: Take note of the size of snapshot 5: Hard refresh and go back to step 3 On every repetition, the footprint seems to grow by ~20MB and the current views aren't clear on where the issue is (seems to be a lot of things without allocation stacks, or everything grows proportionally). The SavedFrames count seems to get higher than I expected. Recording allocation stacks doesn't seem to make a difference. I'll attach two snapshots that are from an example first load, and the corresponding 10th or so load, with a difference of 25MB vs 250MB or so.

First snapshot taken after game is loaded in a new tab.

Nevermind, subsequent snapshots are too large to attach on here. But it is recreateable.

I can repro without enabling allocation stack recording.

5 refreshes, with allocation stacks: http://media.fitzgeraldnick.com/dumping-grounds/tanx-with-stacks.fxsnapshot The original was ~20mb, this is ~75mb. Dominator tree shows that most of the memory is tied up in some kind of `window.app.assets` structure, and much of the children dominated by that were allocated in a `_parseAssets` method. I think this is a legit leak in Tanx itself, but it is hard to make further progress without the unminified source. Can we find people who originally wrote this, debug it with them, and write up a case study?

Building the unminified source to get more info; I'll reach out to them, I think they'll be at GDC next week.

I have seen this behavior as well on a visualization I've been running the memory tool on a bunch. You can see in the dominator tree view there is an "objects > Function" with retained sizes of 13mb and 10mb respectively. These are both retained between refreshes. Live URL: http://gregtatum.com/poems/wandering-lines/ Code: https://github.com/TatumCreative/wandering-lines Recording allocation stacks on the un-minified code it looks like this is what is being retained: https://github.com/TatumCreative/wandering-lines/blob/master/index.js#L170-L174 Is the requestAnimationFrame somehow retaining the reference between refreshes?

Each refresh uses a different JSCompartment, meaning that it gets a different global object, JSScripts are recreated, etc... It should be impossible for something in the new compartment to reference and hold alive anything from the old compartment.

Seeing it here too: https://wfwalker.github.io/mc-choir/ This just decodes a handful of small mp3s as arraybuffers -- it looks like the arraybuffers stick around when using the tool. In about:memory, the window stays alive long after the tab is closed, and with it arraybuffers from several refreshes. Does not happen if you don't use the tool. I think this should be a higher priority since this could be sucking up memory long after a developer is done debugging. This page uses services workers, so that could play a part, but the mp3s cached are small; its the decoded arraybuffers that get huge. These could be platform bugs, but starting to feel like the tool is causing it.

(In reply to Jordan Santell [:jsantell] [@jsantell] (Please needinfo) from comment #10) > Seeing it here too: https://wfwalker.github.io/mc-choir/ > > This just decodes a handful of small mp3s as arraybuffers -- it looks like > the arraybuffers stick around when using the tool. In about:memory, the > window stays alive long after the tab is closed, and with it arraybuffers > from several refreshes. Does not happen if you don't use the tool. I think > this should be a higher priority since this could be sucking up memory long > after a developer is done debugging. > > This page uses services workers, so that could play a part, but the mp3s > cached are small; its the decoded arraybuffers that get huge. These could be > platform bugs, but starting to feel like the tool is causing it. In this test case, it is ArrayBuffers that are leaking as we keep refreshing. All of them are considered roots with a mJSChannels[i] edges which is something related to media. Looks like this is a platform leak to me. I tried doing an about:memory "minimize memory usage" and it had no effect. https://dxr.mozilla.org/mozilla-central/search?tree=mozilla-central&q=mJSChannels Paul, any idea why repeatedly refreshing the page from comment 10 would lead to ArrayBuffer objects being retained for a long time via mJSChannels[i] edges?

Probably a bug ? I think those would be from `decodeAudioData` or something.