Kyle Huey claimed to have fixed this, but it keeps being reported.\</joke>

We have a lot of open bugs where users have noticed runaway memory usage on particular web sites. Maybe now is a good time to figure out how to investigate them.

We've got a lot of code that produces information about memory usage (CC logging, heap dumping, the ubi stuff, there's even a dominator tree analysis for the heap, exposed as "View: Dominators" in the Memory tab of the DevTools) but no standard approach that actually pinpoints problems. And the tools we have aren't considered super trustworthy by engine hackers.

The GC logs, in combination with find_roots.py (from https://github.com/amccreight/heapgraph/ ) will tell you why GCed things are alive. These have been used for many years to find leaks. The main drawback is that if you can't reproduce the problem yourself, then it can be difficult to get these logs from a user, because they are large and contain a lot of information people probably don't want to share.

(In reply to Jason Orendorff [:jorendorff] from comment #0)

And the tools we have aren't considered super trustworthy by engine hackers.

What memory tools do people consider untrustworthy and why?

I'm not sure which cases Jason was thinking about, but one thing that bit us recently was the retained paths graph in the dominators view of the devtools memory tab. We only display the N shortest retaining paths, which is a reasonable choice but sent us down a rabbit hole briefly under the assumption that the displayed paths were the only paths keeping an object alive.

That's what I had in mind. (This conversation moved to email, but there was no real conclusion as to what should be done. Leaving ni?me for the new year.)