Confirmed users
110
edits
DevTools/Memory/Roadmap: Difference between revisions
Jump to navigation
Jump to search
updated current requirements
(Created page with " == Overview == We want to ship memory tools built-in to the [https://developer.mozilla.org/en-US/docs/Tools Firefox Developer Tools] for web and firefox developers to identi...") |
(updated current requirements) |
||
| Line 3: | Line 3: | ||
We want to ship memory tools built-in to the [https://developer.mozilla.org/en-US/docs/Tools 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. | We want to ship memory tools built-in to the [https://developer.mozilla.org/en-US/docs/Tools 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 [https://developer.mozilla.org/en-US/docs/Tools/Performance 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. | 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 === | === 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 ==== | ==== 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 ==== | ==== 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 ==== | ==== 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 === | === Users/Use Cases === | ||
==== Web | |||
==== | * [https://bugzilla.mozilla.org/show_bug.cgi?id=933026 Web developers wanting to identify what’s using memory on their web app], as well as [https://bugzilla.mozilla.org/show_bug.cgi?id=933006 in real time, by type] | ||
==== | * FxOS developers [https://bugzilla.mozilla.org/show_bug.cgi?id=962304 targeting low-memory devices] wanting to use as little memory as possible, monitoring memory consumption with a “high-water mark” in mind. | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1011224 FxOS developers wanting to debug memory issues on device/simulator] | |||
* Firefox engineers wanting to solve memory issues in Firefox with [https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox browser toolbox] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=933048 Web developers, Firefox engineers wanting to solve short-term memory leak issues] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=979723 compare memory between two points in time] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=957791 Should provide ways via console/gcli to show paths to objects that are expected to be collected] | |||
==== Need to turn into actionable issues ==== | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=934015 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. | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=934022 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) | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=932553 show when there are orphaned DOM fragments] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=940738 show memory/count of event handlers] | |||
== Requirements == | == Requirements == | ||
[https://bugzilla.mozilla.org/buglist.cgi?component=Developer%20Tools%3A%20Memory&product=Firefox&bug_status=__open__&list_id=12127556 Open Memory Bugs] | |||
=== QUESTIONS === | |||
== | * Can we get an [https://developer.chrome.com/devtools/docs/memory-profiling-files/collected.png 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) | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=934022 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? [http://memoryanalyzer.blogspot.com/2008/05/automated-heap-dump-analysis-finding.html Eclipse MAT is interesting]. Definitely v2. | |||
=== Performance Tools === | |||
*[https://bugzilla.mozilla.org/show_bug.cgi?id=1136945 GC]/[https://bugzilla.mozilla.org/show_bug.cgi?id=1128083 CC Markers] in timeline | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1148836 Allocation pressure graph] | |||
=== Memory Tools === | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=960776 Heap View] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=960780 Heap Diff View] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1149367 Dominator Tree View] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1149379 Force GC] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1149385 Paths from GC View] | |||
* Allocations by frame | |||
* Allocations by time/type | |||
* Memory Timeline ? | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=962304 Show Total Process Consumption (like current performance tool)] | |||
* Ability to add a high-water mark | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=960765 inspect heap state along timeline] | |||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=960770 diff heap state via timeline selection] | |||
=== | === Additional Tools === | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=960675 console method to find leaked objects’ paths] | |||
* [https://bugzilla.mozilla.org/ | * [https://bugzilla.mozilla.org/show_bug.cgi?id=960662 console method to report retained size of object] | ||
==== Additional Info ==== | |||
* [http://fitzgeraldnick.com/weblog/54/ Fitzgen on the platform memory API] | * [http://fitzgeraldnick.com/weblog/54/ Fitzgen on the platform memory API (2014)] | ||
* [https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#Function_Properties_of_the_Debugger.Memory.prototype_Object Debugger.Memory API] | * [https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#Function_Properties_of_the_Debugger.Memory.prototype_Object Debugger.Memory API] | ||
== Design == | == Design == | ||
| Line 43: | Line 93: | ||
* [https://people.mozilla.org/~dhenein/devtools/memtools/#/memory interactive wireframes] | * [https://people.mozilla.org/~dhenein/devtools/memtools/#/memory interactive wireframes] | ||
| Line 56: | Line 100: | ||
common in many other memory tools, to establish terminology used, not necessarily for implementing in the Firefox memory tools. | 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. | 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. | ||
| Line 80: | Line 124: | ||
View that compares the difference between two heaps, usually showing difference in size and class counts of objects. | View that compares the difference between two heaps, usually showing difference in size and class counts of objects. | ||
=== Allocations By | === Allocations By Frame === | ||
A stack view with allocations performed in each frame — similar to the current [https://developer.mozilla.org/en-US/docs/Tools/Performance Firefox Developer Tools performance allocation view]. | A stack view with allocations performed in each frame — similar to the current [https://developer.mozilla.org/en-US/docs/Tools/Performance Firefox Developer Tools performance allocation view]. | ||
| Line 86: | Line 130: | ||
=== Allocations By Time/Type === | === Allocations By Time/Type === | ||
A slice of allocations that occurred in a timerange, able to view by type (like | A slice of allocations that occurred in a timerange, able to view by type (like a heap view), like [https://developer.chrome.com/devtools/docs/memory-profiling-files/collected.png Chrome’s allocation timeline]. | ||
== Timeline/Milestones == | |||
* Requirements: Mid Q2 | |||
* Ship: Mid Q3 | |||
== Evaluation Metrics == | |||
== Prior Art == | == Prior Art == | ||
| Line 100: | Line 150: | ||
|- | |- | ||
!Tool | !Tool | ||
! | !Heap View | ||
!Dominator View | !Dominator View | ||
!Paths View | !Paths View | ||
| Line 180: | Line 230: | ||
=== Eclipse MAT === | === Eclipse MAT === | ||
* [http://help.eclipse.org/indigo/topic/org.eclipse.mat.ui.help/gettingstarted/basictutorial_histogram.png Histogram tool] ( | * [http://help.eclipse.org/indigo/topic/org.eclipse.mat.ui.help/gettingstarted/basictutorial_histogram.png Histogram tool] (heap view), dominator view, path to GC, etc. | ||
* [http://memoryanalyzer.blogspot.com/2008/05/automated-heap-dump-analysis-finding.html leak hunter tool] | * [http://memoryanalyzer.blogspot.com/2008/05/automated-heap-dump-analysis-finding.html leak hunter tool] | ||
* | * Interesting [http://help.eclipse.org/indigo/topic/org.eclipse.mat.ui.help/tasks/queryingheapobjects.html SQL-like query] for the heap. | ||
* Seems like a very [http://help.eclipse.org/indigo/topic/org.eclipse.mat.ui.help/tasks/comparingdata.html complicated heap diff mode.] | * Seems like a very [http://help.eclipse.org/indigo/topic/org.eclipse.mat.ui.help/tasks/comparingdata.html complicated heap diff mode.] | ||
| Line 194: | Line 244: | ||
=== Chrome DevTools === | === Chrome DevTools === | ||
* Has [https://developer.chrome.com/devtools/docs/javascript-memory-profiling#summary-view summary view] ( | * Has [https://developer.chrome.com/devtools/docs/javascript-memory-profiling#summary-view summary view] (heap view), diff two snapshots in [https://developer.chrome.com/devtools/docs/javascript-memory-profiling#comparison-view comparison view], path view via [https://developer.chrome.com/devtools/docs/javascript-memory-profiling#containment-view containment view], and a [https://developer.chrome.com/devtools/docs/javascript-memory-profiling#dominators-view dominator view] in the heap snapshot profiler. | ||
* Has a [https://developer.chrome.com/devtools/docs/memory-profiling-files/collected.png 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. | * Has a [https://developer.chrome.com/devtools/docs/memory-profiling-files/collected.png 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. | ||
* [https://developer.chrome.com/devtools/docs/timeline#memory-mode Chrome Timeline] can record memory usage over time (by very high level type). | * [https://developer.chrome.com/devtools/docs/timeline#memory-mode Chrome Timeline] can record memory usage over time (by very high level type). | ||