Confirmed users
125
edits
DevTools/Memory/Roadmap: Difference between revisions
Jump to navigation
Jump to search
→Heap Graph Analyses: talking about heap graph analyses
(→Design: WIP adding platform apis and latest sketches) |
(→Heap Graph Analyses: talking about heap graph analyses) |
||
| Line 121: | Line 121: | ||
==== 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 === | ||