DevTools/Memory/Roadmap

Overview

We want to ship memory tools built-in to the Firefox Developer Tools for web and firefox developers to identify, locate, and resolve memory issues related to memory bloat and leaks. If the memory tool can inform, educate and empower developers in each of these 3 stages, then we believe that this tool will successfully solve memory bloat and leak.

Originally, this tool was going to handle all issues involving memory — in 2014, it was agreed upon that this memory tool will focus on memory bloat and leaks, while the Performance tool handles performance issues, including issues that arise from GC pauses from allocations. The performance tool will be used to *identify* memory issues in the first place, as a springboard into using the memory tools for further debugging.

The platform work for the memory tool was started in 2014, with initial requirements gathering and work on the memory APIs. At the time of writing (April 2015), we now flesh out the use-cases and requirements on the front end experience.

Tool Stages

Description of the debugging stages, with which features can solve different issues along the way. View Feature Descriptions sections for definitions of the components of memory tools used in this document.

Stage 1: Identify

It should be easy to discover when there is a memory problem in the current target. This can be as obvious as an OOM crash, or a more subtle leak. For identifying leaks, the performance tool’s timeline can be used to observe memory growth over time, and observing GC events not reducing memory consumption. For bloat issues, the memory tool itself should be used to identify types of objects that are unreasonably large.

Stage 2: Locate

A Heap View can be used to identify areas that are taking up more than expected amounts of memory by viewing the heap, sorting by size or allocations, and grouping by type/class. With similar sorting and grouping capabilities, a heap diff view can illustrate uncollected objects after a cycle, highlighting suspiciously large areas of memory that have not been collected. For finding accumulation points, the dominator view can also be used.

Stage 3: Resolve

Dominator tree views and path (from GC root) views are two ways to provide enough context of a memory issue to fix it.

Allocations by frame (currently in performance) and allocations by type/time view can also be used for additional information on where certain allocations are occurring if needed.

Users/Use Cases

• Web developers wanting to identify what’s using memory on their web app, as well as in real time, by type
• FxOS developers targeting low-memory devices wanting to use as little memory as possible, monitoring memory consumption with a “high-water mark” in mind.
• FxOS developers wanting to debug memory issues on device/simulator

• Firefox engineers wanting to solve memory issues in Firefox with browser toolbox
• Web developers, Firefox engineers wanting to solve short-term memory leak issues
• compare memory between two points in time
• Should provide ways via console/gcli to show paths to objects that are expected to be collected

Need to turn into actionable issues

• Finding longterm memory leaks via just snapshots. — Chrome has their “recording” and snapshots completely separated, IE11/VS2015 have them rolled together. Maybe we can get creative on how to do this.
• When a GC event occurs, I should be able to see the objects being collected and where they were created and where they were released. (current performance allocations view kind of does this; we can show were objects are created, but cannot show what got collected AFAIK)
• show when there are orphaned DOM fragments
• show memory/count of event handlers

Requirements

Open Memory Bugs

QUESTIONS

• Can we get an allocations by time/type view via census timeline, and using heap diffs on censuses?
• Should we show allocation views in memory, even if redundant with performance tool?
• What “types” of objects can we classify in a high-level timeline? (Chrome has heap, document, nodes, event listeners)
• can we get info about when a specific object got collected? IIRC, Fitzgen said once an object is GC’d we can’t get info on it.
• Ideas on “leak hunter” tool? Eclipse MAT is interesting. Definitely v2.

Performance Tools

• GC/CC Markers in timeline
• Allocation pressure graph

Memory Tools

• Heap View
• Heap Diff View
• Dominator Tree View
• Force GC
• Paths from GC View
• Allocations by frame ?
• Allocations by time/type ?
• Memory Recording Timeline ?
• Memory Timeline: Show Total Process Consumption (like current performance tool)
• Memory Timeline: Ability to add a high-water mark
• Memory Timeline: inspect heap state along timeline
• Memory Timeline: diff heap state via timeline selection

Additional Tools

• console method to find leaked objects’ paths
• console method to report retained size of object

Additional Info

• Fitzgen on the platform memory API (2014)
• Debugger.Memory API

Design

• Original mockup
• interactive wireframes

Feature Description

A collection of feature descriptions referenced in the prior art, as well as requirements. These are features common in many other memory tools, to establish terminology used, not necessarily for implementing in the Firefox memory tools.

Heap View

This is different in every tool, but usually a high level look at a heap snapshot, able to be sorted by class/type/allocation site/module, etc., with allocation counts, size, overall memory consumption, and a first step to discovering where a memory issue is hiding.

Dominator View

A view showing which objects dominate other objects. In OptimizeIt, this is known as a reduced reference graph.

Paths View

A view showing, from the GC root, a path of object references leading to the object in question.

Force GC

Utility to force garbage collection.

Leak Detection

This is pretty different in each tool, if it exists. Usually a smart analysis with some heuristics to point the developer to a potentially leaky object.

Heap Diffs

View that compares the difference between two heaps, usually showing difference in size and class counts of objects.

Allocations By Frame

A stack view with allocations performed in each frame — similar to the current Firefox Developer Tools performance allocation view.

Allocations By Time/Type

A slice of allocations that occurred in a timerange, able to view by type (like a heap view), like Chrome’s allocation timeline.

Timeline/Milestones

• Requirements: Mid Q2
• Ship: Mid Q3

Prior Art

There are many other memory profiling tools out there; when researching this, we look at not only other browser developer tools, but also other environments’ tooling, like Java. Many of the tools contain many of the same features, listed below in the overview graph, with unique features for each product explained after.

Comparison

Other Memory Tools

Tool	Heap View	Dominator View	Paths View	Force GC	Leak Detect	Heap Diffs	Allocs by stack	Allocs by time/type
YourKit Java Profiler	✓	✓	✓		✓	✓	✓	✓
Eclipse MAT (tut)	✓	✓	✓		✓	✓
Borland OptimizeIt	✓	✓	✓	✓	✓	✓	✓	✓
Chrome DevTools	✓	✓	✓	?		✓		✓
IE11 DevTools	✓	✓	✓			✓
VS2015	✓	✓	✓			✓

YourKit Java Profiler

• Can snapshot on high memory load
• Has a Merged Paths view, that’s similar to path from GC view, but does not show path of individual objects, but shows paths from multiple objects grouped by class.
• Has “incoming references” view, inverse of references.
• Has automation inspection view, which highlights potential memory issues. Not sure what all this provides, but looks like a good “coach” for memory issues.
• Has GC view showing times of GC, length of GC, and GC in the context of a call tree

Eclipse MAT

• Histogram tool (heap view), dominator view, path to GC, etc.
• leak hunter tool
• Interesting SQL-like query for the heap.
• Seems like a very complicated heap diff mode.

Borland OptimizeIt

• The paths view (reference graph) can be inverse (outgoing reference graph)
• Allocation Backtrace - Can view any class/type of object and list all allocation sites for that type, sorted by number
• Aggregated Graph View - A graph visualization of the call stack, with each node being a frame, with red nodes indicating the frame allocates objects (the more saturated the red, the more allocations in this frame)
• Can disable GC.

Chrome DevTools

• Has summary view (heap view), diff two snapshots in comparison view, path view via containment view, and a dominator view in the heap snapshot profiler.
• Has a heap allocations timeline that displays allocation pressure, color coding whether or not the objects are still alive at the current time (or at the end of the recording). Uses the same views as the memory profiler to compare the heap snapshots during the timeline.
• Chrome Timeline can record memory usage over time (by very high level type).
• Does not have explicit GC — but GC’s on memory snapshot. Timeline tool has a force GC, however.

IE11/VS2015

• Seem to be based on the same infrastructure.
• Caller/callee mode (inverting), like incoming/outgoing reference paths.
• “Just my Code” (VS2015) and “Show built-ins” (IE11), a way to hide platform data.
• Toggleable ability to display circular references
• VS2015 - can set a threshold line in memory timeline — great for a “memory emulator” feature?
• Very beautiful overview page showing diffs in heap snapshots during the timeline recording.

Current Mozilla Memory Tools

• Memory reporting APIs
• about:memory
• Memory Profiler (deprecated addon)
• GC/CC dump analyzers
• Dark Matter Detector