Confirmed users
110
edits
DevTools/Memory/Roadmap: Difference between revisions
Add meta bug for v1
(→Design: WIP adding platform apis and latest sketches) |
(Add meta bug for v1) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 47: | Line 47: | ||
== Requirements == | == Requirements == | ||
[https://bugzilla.mozilla.org/buglist.cgi?component=Developer%20Tools%3A%20Memory&product=Firefox&bug_status=__open__&list_id=12127556 | [https://bugzilla.mozilla.org/show_bug.cgi?id=1195323 meta: Memory Tools v1, Fx44] | ||
[https://bugzilla.mozilla.org/buglist.cgi?component=Developer%20Tools%3A%20Memory&product=Firefox&bug_status=__open__&list_id=12127556 Memory Tools Component in Bugzilla] | |||
=== QUESTIONS === | === QUESTIONS === | ||
| Line 97: | Line 99: | ||
* [http://fitzgeraldnick.com/weblog/54/ Fitzgen on the platform memory API (2014)] | * [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 121: | Line 122: | ||
==== Heap Graph Analyses ==== | ==== Heap Graph Analyses ==== | ||
Given a heap graph, we can run various analyses on it that give us different bits of information. | Given a heap graph, we can run various analyses on it that give us different bits of information. Note that the heap graph can be either the live heap graph or a serialized heap snapshot. We can run our analyses on either heap graph. Depending on the analysis, and how expensive computing it is, it may make sense to prefer the live heap graph or a serialized heap snapshot for any given analysis. Heavier, more expensive computations may benefit from being run exclusively on heap snapshots because the heap snapshot can be deserialized in a worker thread and the analysis run there so that it doesn't jank the main thread. As a rule of thumb, if the analysis is cheaper than taking a heap snapshot, run it on the live heap graph. Otherwise, when the analysis is more expensive than taking a heap snapshot, take the heap snapshot and then run the analysis in a worker thread. | ||
===== Dominator Trees ===== | |||
If x '''dominates''' y, then any path from the global window to y must pass through x. We can use this information in two practical ways: | |||
# If you nullify all references to x, every y such that x dominates y will also become unreachable and will eventually be garbage collected. | |||
# We can calculate the retained size of x. That is, the amount of memory that will be reclaimed if x (and therefore also every y such that x dominates y) were to be garbage collected. | |||
It also lets us sort by retained size and present the dominator tree directly. This lets developers easily navigate the most expensive (in terms of retained size) objects in their heap. | |||
===== Breadth First Search ===== | |||
By doing a BFS in the heap graph from the GC roots to any given object, we find the shortest retaining path(s) for that object. | |||
In the frontend, we can use these paths to construct a developer-friendly label for that object. Often the label we provide will be a snippet of JavaScript that can be evaluated in the console. For example: "window.MyApp.WidgetView.element". Other times, we will be forced to display labels that cannot be evaluated in the console: "window.[[requestAnimationFrame renderLoop]].[[ closure environment ]].player.sprite". | |||
=== Mockups === | === Mockups === | ||