Yes it is. I also wrote more about the backend implementation on lobste.rs <https://lobste.rs/s/cvtz0x/firefox_s_new_memory_tool https://lobste.rs/s/cvtz0x/fire

Yes it is. I also wrote more about the backend implementation on lobste.rs <https://lobste.rs/s/cvtz0x/firefox_s_new_memory_tool https://lobste.rs/s/cvtz0x/firefox_s_new_memory_tool >: 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 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/a8ed7dd831d1969a5a1a8636e63bd93d6aeaf94a/js/public/UbiNode.h#31-163 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/ 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/a8ed7dd831d1969a5a1a8636e63bd93d6aeaf94a/mfbt/FastBernoulliTrial.h#18-172 https://dxr.mozilla.org/mozilla-central/rev/a8ed7dd831d1969a... We use this for sampling object allocations to give insight into GC pressure.