Confirmed users
125
edits
DevTools/Memory/Roadmap: Difference between revisions
Jump to navigation
Jump to search
→Design: WIP adding platform apis and latest sketches
m (→QUESTIONS) |
(→Design: WIP adding platform apis and latest sketches) |
||
| Line 100: | Line 100: | ||
== Design == | == Design == | ||
=== Platform APIs === | |||
Platform APIs are being tracked in [https://bugzilla.mozilla.org/show_bug.cgi?id=961331 (Meta) DevTools platform APIs for heap / memory analysis]. The platform APIs generally fall into one of two categories: (1) GC related APIs for debugging pauses originating from the collector, or (2) analyses of the heap graph (live heap or serialized snapshot). | |||
==== GC APIs ==== | |||
The various GC APIs are exposed on SpiderMonkey's <code>Debugger</code> API, under the <code>Debugger.Memory</code> qualifier. [https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory Documentation for <code>Debugger.Memory</code> APIs.] | |||
These APIs are concerned with | |||
* Why a GC was triggered (hint: allocating too much stuff) | |||
* What are the allocations that applied pressure on the collector (or, which allocations collectively triggered a GC) | |||
* Monitoring how long GCs are taking, whether they are incremental or not, etc | |||
Each of these APIs is centered around helping developers minimize GC pauses in their application. | |||
==== Heap Graph Analyses ==== | |||
Given a heap graph, we can run various analyses on it that give us different bits of information. | |||
TODO | |||
=== Mockups === | |||
==== Latest Sketches ==== | |||
PDF (sorry!): [[File:Memory-tool-mockup-sketch.pdf|thumbnail]] | |||
Each section below describes one facet of those sketches. | |||
===== Overview ===== | |||
This is primarily driven by the [https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#take-census Debugger.Memory.prototype.takeCencus API]. Gives an overview of the contents of the heap over time. Aggregate counts and aggregate shallow (not retained) sizes, along with percentages, and a + or - indicating whether it is growing or shrinking. | |||
You will be able to group by allocation site, type (Array, DOMException, js::Shape, etc), constructor, prototype, etc. | |||
Feedback given by njn: | |||
<blockquote> | |||
One thing I've learned over the years is that everybody always thinks | |||
they want a graph showing memory usage vs. time, but in practice such | |||
graphs are pretty but largely useless. Because all you ever do with | |||
them is find the peak usage point and then look at that point in | |||
detail. Because what's the point of optimizing anything other than the | |||
peak? | |||
This implies two things (IMO): | |||
* The graph stuff is much less important than the snapshot stuff. | |||
* The ability to automatically get a snapshot at peak usage (or close to peak, because getting the exact peak is tricky) is useful. | |||
</blockquote> | |||
Response to feedback by fitzgen: | |||
<blockquote> | |||
Agreed that peak is most important, but the graphs help you do two things: | |||
* Identify the peak. | |||
* Correlate that peak with interactions or events on the page. | |||
Perhaps we don't need so many categories and the overview, but just a simple size-of-tab graph. | |||
Automatic heap snapshots when near the peak sounds great. | |||
</blockquote> | |||
===== Allocations and GC ===== | |||
Because this view is primarily about minimizing GC pauses (and jank associated therein), this should be part of the performance panel, rather than the memory panel. | |||
Anyways, this overlays GCs on top of a graph of the rate of allocation. Below is the allocations tree (and we could make it toggle to a flame graph/chart and make the tree invert-able, too). Size and count of allocations are shown as well as the percentage of allocations. | |||
This is using the [https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#Allocation_Logging allocations log] and [https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#Debugger.Memory_Handler_Functions <code>Debugger.Memory</code>'s <code>onGarbageCollection</code> hook]. | |||
===== Heap Snapshots: Dominator Tree ===== | |||
Computing dominator trees is expensive enough that we can only really do it when the user explicitly asks for it (unlike taking a census), so that's why it is part of heap snapshots. This is a view of the things in the heap sorted by biggest '''retained''' size, and the set of things they are each keeping alive in turn. | |||
===== Heap Snapshots: Retaining Paths ===== | |||
This view shows you the N shortest paths from a GC root to a given GC thing. Unsure how a thing's dominator is keeping it alive and feel like it should have been collected? Here are all the ways. This is probably a side panel of the dominator tree, rather than its own tab in the tool. | |||
==== Older Mockups ==== | |||
Pretty, but aren't as clearly solving our user stories / requirements. Not sure what everything here is supposed to be. | |||
* [https://bug960671.bugzilla.mozilla.org/attachment.cgi?id=8361231 Original mockup] | * [https://bug960671.bugzilla.mozilla.org/attachment.cgi?id=8361231 Original mockup] | ||
* [https://people.mozilla.org/~dhenein/devtools/memtools/#/memory interactive wireframes] | * [https://people.mozilla.org/~dhenein/devtools/memtools/#/memory interactive wireframes] | ||
== Feature Description == | == Feature Description == | ||