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

Timestamp:

Aug 23, 2018 9:51:48 PM (6 years ago)

Author:

Simon Fraser

Comment:

--

Inspecting the GC heap

@@ -7 +7 @@
 In 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.
 
-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.
+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. These objects are referred to as '''roots''': they act as the root of a tree (or bush) of other objects in the GC heap.
 
 == Why might you want to inspect it? ==
@@ -43 +43 @@
 7. 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:
   [[Image(gc-heap-inspector.png, 1200px)]]
+  and as you scroll down you'll see all the objects in the GC heap.
+
+== Using the GC Heap Inspector page ==
+
+The page currently has four main sections.
+
+The 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.
+
+The second section is '''All paths to…''' and this fills in when you click the "Show all paths" button for an object.
+
+The 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:
+{{{
+HTMLCollection cell 0x116c9b840 wrapped 0x1161311f0 “url http://localhost:8800/IndexedDB/value.htm” (GC root—Weak sets, Reachable from HTMLCollection ownerNode)
+}}}
+
+Let's break this down.
+* {{{HTMLCollection}}}: the C++ type of the object (exposed to JS as a JSHTMLCollection object).
+* {{{cell 0x116c9b840}}}: the address of the JSCell representing this object
+* {{{wrapped 0x1161311f0}}}: this address of the "wrapped" object, i.e. the underlying HTMLCollection object.
+* {{{“url http://localhost:8800/IndexedDB/value.htm”}}} this shows the URL of the document that the wrapper belongs to.
+* {{{(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.
+
+Finally 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.