Changes between Version 4 and Version 5 of Inspecting the GC heap


Ignore:
Timestamp:
Aug 23, 2018 9:51:48 PM (4 years ago)
Author:
Simon Fraser
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Inspecting the GC heap

    v4 v5  
    77In the implementation, objects in the GC heap are referenced through JSCell pointers. The heap is managed by [https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/heap/Heap.h JavaScriptCore/heap/Heap.h] and the process of visiting the JSCells for the purpose of GC by [https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/heap/SlotVisitor.h JavaScriptCore/heap/SlotVisitor.h]. Cells that are visited are "marked" to avoid visit cycles.
    88
    9 Some objects in the GC heap are also connected to objects in the C++ native world, for example things like DOM nodes and event handlers that are exposed to script. Their lifetime rules get more complex, and it's often here that bugs creep in.
     9Some objects in the GC heap are also connected to objects in the C++ native world, for example things like DOM nodes and event handlers that are exposed to script. Their lifetime rules get more complex, and it's often here that bugs creep in. These objects are referred to as '''roots''': they act as the root of a tree (or bush) of other objects in the GC heap.
    1010
    1111== Why might you want to inspect it? ==
     
    43437. Now in the browser navigate to [http://0.0.0.0:8999/gc-heap-inspector.html]. You'll see the GC heap inspector banner. Now drag your {{{~/Desktop/values-heap.json}}} file onto the badge in the top right. You should see something like this:
    4444  [[Image(gc-heap-inspector.png, 1200px)]]
     45  and as you scroll down you'll see all the objects in the GC heap.
     46
     47== Using the GC Heap Inspector page ==
     48
     49The page currently has four main sections.
     50
     51The first is '''Paths to roots''' (probably a bad name that needs fixing). Arbitrarily, I've decided that interesting objects are '''Windows''' and '''HTMLDocuments''', because if you leak these, you tend to leak lots of other data. A ''path'' here is a chain of references from some root object to the object of interest. Often, there can be multiple such paths, so the UI shows the shortest one.
     52
     53The second section is '''All paths to…''' and this fills in when you click the "Show all paths" button for an object.
     54
     55The third section is '''Roots'''. This lists all objects that are GC roots, and if you expand a category, you'll see that it lists why something is considered a root. For example:
     56{{{
     57HTMLCollection cell 0x116c9b840 wrapped 0x1161311f0 “url http://localhost:8800/IndexedDB/value.htm” (GC root—Weak sets, Reachable from HTMLCollection ownerNode)
     58}}}
     59
     60Let's break this down.
     61* {{{HTMLCollection}}}: the C++ type of the object (exposed to JS as a JSHTMLCollection object).
     62* {{{cell 0x116c9b840}}}: the address of the JSCell representing this object
     63* {{{wrapped 0x1161311f0}}}: this address of the "wrapped" object, i.e. the underlying HTMLCollection object.
     64* {{{“url http://localhost:8800/IndexedDB/value.htm”}}} this shows the URL of the document that the wrapper belongs to.
     65* {{{(GC root—Weak sets, Reachable from HTMLCollection ownerNode)}}}: this tells us why this object is considered a GC root; in this case, the ownerNode of the HTMLCollection is still alive and references this HTMLCollection.
     66
     67Finally there is the '''All Objects by Type''' section, that lists all the objects in the GC heap (thousands of them). Many of these are built-in objects and functions and not very interesting.