Firefox’s New Memory Tool

Thanks to the hard work of Steve Fink, these days it has an O(n) marking algorithm. See https://bugzilla.mozilla.org/show_bug.cgi?id=1164294 for the details.

Edit to address your questions more directly:

> how aggressive is Firefox in holding on to weakly referenced objects?

They are just collected at the next GC slice where they are no longer retained. SpiderMonkey doesn't do anything to try and eagerly collect them. GC slices generally won't happen until either there has been enough pressure (allocations) to trigger one or the user is inactive for N amount of time. There are tons of GC triggering heuristics and some are probably not optimal. It is on the GC team's TODO list to revisit and clean these up.

> does Firefox always continue to allocate memory from the host OS, or is there some threshold where it starts to let things slip?

The threshold of how much is allocated before triggering GC grows as the retained set's size grows. This is bounded by available memory.

Aaaaand I have a meeting I need to go attend.

Some websites break. In my experience very few though.

Also many seem to be missing a lot of ads. This is terrible, cough cough.

Privacy Badger is an EFF project.

Hi folks,

For the last year or so, my coworker Jim Blandy and I have been designing and implementing APIs in SpiderMonkey (Firefox’s JavaScript engine) to support various kinds of memory allocation/retention introspection. We are finally shipping a frontend to users as well, and this blog post is an intro to that. This is very much the tip of the iceberg and we wanted to just start shipping since we’ve been building APIs for so long, but this is really a fraction of the things planned. Nightly already has filtering/searching and will soon have import/export of snapshots as well as diffing <http://i.imgur.com/qjWOERs.gif >. Dominator trees and shortest paths from GC roots are incoming as well.

How is this built?

We made an abstraction called “ubi::Node” <https://dxr.mozilla.org/mozilla-central/rev/a8ed7dd831d1969a... > (for “ubiquitous node”) that sees the GC’s heap graph with a traditional nodes-and-edges view so that we don’t have to worry about the difference between (say) an object and some jit code when writing graph analyses. What is cool is that this interface can be backed by either the live heap graph or an offline heap graph. When you save a heap snapshot, we traverse this graph and serialize it into protobuf messages. These can then be reconstructed into an offline graph which you can run analyses on at your leisure.

We also make pretty extensive use of stack capturing, because that is a concrete way to tie retention and GC pressure back to something that feels concrete to users: locations in their source code. I’ve written a bit about how we minimize the overhead of (potentially very frequent) stack captures before by hash consing individual frames so that tails are shared <http://fitzgeraldnick.com/weblog/61/ >. Since then, we have also found a neat way to avoid walking the stack repeatedly if we have already done so once.

If anyone has any questions, please ask away :)

And I made a quick update:

Also, Jim loved writing this comment so much (it is a fun read) that I feel I have to share it :)

https://dxr.mozilla.org/mozilla-central/rev/a8ed7dd831d1969a...

We use this for sampling object allocations to give insight into GC pressure.

https://dxr.mozilla.org/mozilla-central/source/devtools/clie...

(I think there are other parts of the developer tools that also use React and Redux, like the debugger.)

Alternatively, you could email me your crash reports (email in profile) and I could file bug(s) for youe.

Chrome has had memory profiling for at least 2 years. https://developer.chrome.com/devtools/docs/javascript-memory...

How does Firefox's new profiling feature compare?