| | 1 | = Inspecting the GC heap = |
| | 2 | |
| | 3 | == What is the GC Heap? == |
| | 4 | |
| | 5 | The GC ("Garbage Collection") heap is the set of objects whose lifetimes are managed by the JavaScript Garbage Collector. JavaScript does not have explicit memory management functions, so JS object lifetimes are managed by garbage collection. This involves traversing the memory used by those objects, looking for memory values that look like pointers, and deducing that objects are live if any pointer-like values refer to them. When an object no longer has any live references, it can be garbage-collected, and then gets actually destroyed. |
| | 6 | |
| | 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. |
| | 8 | |
| | 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. |
| | 10 | |
| | 11 | == Why might you want to inspect it? == |
| | 12 | |
| | 13 | The primary reason to inspect the GC heap is to get information about why an object is not being destroyed when you think it should be. Often, we see that Document objects stick around longer than we expect (see [https://bugs.webkit.org/show_bug.cgi?id=186214 bug 186214] for more on this). If we capture a GC heap dump at the point where we expect the Document should have been destroyed, we can inspect the output to see what objects reference that Document, thus keeping it alive. We'll work through an example below. |
| | 14 | |
| | 15 | |
