DevTools/Memory/Roadmap

From MozillaWiki
Jump to navigation Jump to search


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

Need to turn into actionable issues

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.
  • If we have a “timeline”, frequently taking a census of the heap, we can either store just the first and most recent state, or store each census. How large are these censuses?
  • Ideas on “leak hunter” tool? Eclipse MAT is interesting. Definitely v2.

---

  • What “type” of information do we get from censuses? constructor name, allocation site (if enabled), primitives, etc
  • What “types” of objects can we classify in a high-level timeline? (Chrome has heap, document, nodes, event listeners)
  • How large is a census? For gmail?
  • How large is a snapshot? For gmail?
  • 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. Can we however, track the absence of an object? So, IDing objects, and having 1+ states to compare to. Census? Snapshot?
  • Memory Profiler - What’s the overlap here? What goals are redundant with this, and/or the performance allocation view? (bug)

Performance Tools

Memory Tools


Additional Tools


Additional Info


Design


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

Evaluation Metrics

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

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

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