JavaScript memory analytics for Chrome developer tools

A memory leak is a gradual decrease in available memory for a computer. Occurs when the program continues to fail to release the temporary memory it uses. JavaScript Web applications also frequently encounter memory-related problems in native applications, such as leaks and overflows, and Web applications need to address garbage collection pauses .

Although JavaScript uses garbage collection for automatic memory management, effective (effective) memory management is still important. In this article we will explore memory issues in the analysis of JavaScript Web applications. When learning about features, be sure to try the relevant cases to improve your understanding of how these tools work in practice. Please read the Memory 101 101 page to help you familiarize yourself with the terminology used in this article. Note:Some of the features we're going to use are currently available only for Chrome Canary browsers. We recommend using this version to get the best tools to analyze your application's memory problems.

The question you need to think about

Overall, when you think you're experiencing a memory leak, you need to think about three questions:

• does my page occupy too much memory? -Timeline Memory Viewing tool (Timeline memories view) and Chrome Task Manager can help you verify that you are using too much memory. Memory View tracks DOM node count, documents count, and JS event listener count during page rendering. As a rule of thumb: Avoid references to DOM elements that are no longer needed, remove unwanted event snooping, and keep in mind when storing chunks of data that you might not be using.
• is there a memory leak on my page? -Object Assignment tracking (objects allocation Tracker) helps you locate leaks by viewing the allocation of JS objects in real time. You can also use the heap Profiler to generate a JS heap snapshot to identify objects that have not been cleaned up by garbage collection by analyzing the differences between the memory graph and the comparison snapshot.
• how often is my page garbage forced collection? -If your page is garbage collected very frequently, it means that your page may be allocated too often for memory usage. The Timeline Memory viewing tool (Timeline memories view) can help you discover the pauses of interest.

Terminology and basic concepts

This section describes the common terminology used in memory analysis , which is also applicable in tools that do memory analysis for other languages. The terminology and concepts are used in the Heap Profiler UI tool and related documentation.

These can help us become familiar with how to use memory analysis tools effectively. If you've ever used something like Java,. NET and other languages such as memory analysis tools, then this will be a review.

Object Size (Sizes)

Think of memory as a chart that contains basic types (like numbers and strings) and objects (associative arrays). It may look like the graph of a series of associated points below.

There are two methods of using memory for an object:

• Direct use of the object itself
• The implicit retention of references to other objects prevents garbage collection (GC) from automatically reclaiming those objects.

When you use the heap Analyzer in Devtools (the heap Profiler, the tool used to analyze memory problems, under Devtools's "Profile" tab), you may be pleasantly surprised to find some columns that display a variety of information. Two of these are: Direct memory (shallow size) and total memory (retained size), what do they mean?

Direct memory consumption (shallow Size, excluding memory consumed by referenced objects)

This is the memory occupied by the object itself.

A typical JavaScript object would have reserved memory to describe the object and store its direct value. In general, only arrays and strings will have significant direct memory consumption (shallow Size). However, strings and arrays often store the main data part in the renderer memory, exposing only a small wrapper object to the JavaScript object stack.

Renderer memory refers to all of the memory used by the page you analyze in the process of rendering: the memory of the page itself + the JS heap in the page that is used in the memory + page triggered by the JS heap in the associated worker process (workers). However, by preventing garbage from automatically reclaiming other objects, a small object can potentially consume a lot of memory indirectly.

Occupies total memory (retained Size, including memory consumed by referenced objects)

Once an object is deleted, the dependent objects referenced by it cannot be referenced by GC root (GC root) , and the memory occupied by them is freed, and an object consumes the total memory that is occupied by those dependent objects.

GC roots are made up of controllers (handles) that are created when a reference to a JavaScript object, whether local or global, is established by the Build-in function (native code) to the V8 engine. All of these controllers can be found in GC roots (GC root) > Handle scope and gc roots > Global handlers for heap snapshots. If you do not have a deep understanding of how browsers are implemented, it may not be understandable to introduce these controllers in this article. GC Root and controller you don't need to care too much.

There are many internal GC roots that are not important to the user. There are several scenarios from an application perspective:

• Window Global Object (in all IFRAME). There is a distance field in the heap snapshot, which is the shortest path length from the window object to the corresponding object.
• The document DOM tree that consists of all the DOM nodes that the document can traverse to. Not all nodes will be referenced by the corresponding JS, but the node with JS reference will be preserved in the case of document existence.
• There are many objects that may have been created when debugging code or in Devtools console (e.g., after some code execution in the console has finished).

Note: We recommend that users do not execute code in the console or enable debug breakpoints when creating a heap snapshot.

The memory map starts with a root, possibly a browser window object or a node Global . JS Module object. How these objects are reclaimed by memory is not under the control of the user.

Objects that cannot be traversed by the GC root will be reclaimed by memory.

Note: the data in the memory and the total memory fields are represented in bytes.

Total memory tree occupied by the object

As we have learned before, the heap is a network of interconnected objects. In the digital realm, this structure is called a graph or memory graph. The graph is made up of nodes (nodes) that are connected by edges (edges), and they are labeled.

• node (Nodes) The label name of the (or object) node is determined by the name of the construction (constructor) function that created them
• Edge (Edges) tag name is the attribute name

Later in this document you will learn how to use the heap analyzer to generate snapshots. From the snapshot generated by the heap analyzer, we can see the distance (distance) This field: refers to the distance from the object to the GC root. If the distances of all objects of the same type are the same, and a small part of the distance is relatively large, then there may be some problem that you need to investigate.

Objects of Domination (Dominators)

Dominating objects is like a tree structure, because each object has a dominant person. The subject of an object may not directly refer to the object it dominates, that is, the dominant object tree structure is not the spanning tree in the diagram.

In the:

• Node 1 domination Node 2
• Node 2 domination node 3,4 and 6
• Node 3 domination node 5
• Node 5 domination node 8
• Node 6 domination node 7

In the example, the node #3 is #10 the dominant person, but #7 it also appears in every #10 path from the GC. Like this, if the B object appears in every path from the root node to the A object, then the B object is the object of the A object.

V8 Introduction

In this section, we will describe some memory-related concepts that are related to V8 JavaScript virtual machines (V8 VMS or VMS). Understanding these concepts is helpful in understanding heap snapshots when analyzing memory.

JavaScript Object Description

There are three primitive types:

• Number (Numbers) (e.g. 3.14159 ...)
• Boolean value (Booleans) (True or false)
• Character type (Strings) (e.g. ' Werner Heisenberg ')

They do not reference other values, they are only leaf nodes or terminating nodes.

The number (Numbers) is stored in one of the following two ways:

• 31-bit integer direct value, called: Small integer (small integers)(SMIs), or
• The heap object, referenced as a heap value . Heap values are used to store data that is not suitable to be stored in SMI form, such as double-precision numbers (doubles), or when a value needs to be packaged (boxed), such as setting the value of the property.

character data is stored in the following two ways:

• vm heap , or
• The external renderer in memory . A wrapper object is created to access the stored location, such as the script resource and other content of the Web page's bread, instead of being copied directly to the VM heap.

The newly created JavaScript object is allocated memory on the JavaScript heap (or vm heap ). These objects are managed by the V8 garbage collector, and they remain in memory as long as there is a strong reference.

The local object is all objects that are not in the JavaScript heap, and unlike the heap objects, they are not processed by the V8 garbage collector during their lifetime, and can only be referenced by the JavaScript wrapper object.

A connection string is an object that is merged by a pair of strings, and is the result of the merge. The connection strings are only merged when necessary. A substring like a connection string needs to be built.

For example: If you connect a and b, you get the string (A, b) which is used to indicate the result of the connection. If you later connect the result to D , you get another connection string ((A, B), D).

Array (Arrays) -An array is an object of numeric type keys. They are widely used when storing large amounts of data in the V8 engine. An object with a key-value pair, like a dictionary, is implemented with an array.

A typical JavaScript object can be stored in one of two types of arrays:

• Named properties, and
• Elements of Digitization

If there are only a few attributes, they are stored directly in the JavaScript object itself.

Map -An object used to describe the object type and its structure. For example, maps can be used to describe the structure of objects to enable quick access to object properties

Object groups

Each local object group consists of a set of objects that are related to each other. For example, a DOM subtree, each node can access its parent element, the next child element and the next sibling element, which constitute an association diagram. It is important to note that local elements are not represented in the JavaScript heap-This is why their size is zero, and its wrapper object is created.

Each wrapper object has a reference to the local object that is used to pass operations on these local objects. These local objects also have a reference to the wrapper object. But this does not create a loop that cannot be retracted, and the GC is intelligent enough to distinguish the local objects that have not already referenced the wrapper object and release them. However, if a wrapper object is not released, it will retain all object groups and related wrapper objects.

Prerequisites and helpful tips for Chrome Task Manager

Note: When using chrome for memory analysis, it's a good idea to set up a clean test environment

Open Chrome's memory manager, observe the memory fields, do the related actions on a page, you can quickly locate this operation will cause the page to occupy a lot of memory. You can find the memory Manager from the Chrome menu > Tools or by pressing SHIFT + ESC.

After opening, right-click on the header to select the memory used by Javasscript.

Locating memory problems with Devtools timeline

The first step in solving the problem is to be able to prove that the problem exists. This requires creating a reproducible test as a baseline measure of the problem. Without a reproducible program, there is no reliable measure of the problem. In other words, if there are no benchmarks to compare, there is no way to know which changes are causing the problem.

The Timeline Panel (Timeline panel) is useful for discovering when a program is out of the question. It shows the moment when your web app or website loads and interacts. All events: from loading resources to solving JavaScript, style calculations, garbage collection pauses and page redraw. are represented on the timeline.

When analyzing memory issues, the memory view on the timeline panel can be used to observe:

• Total Memory used – is memory usage growing?
• DOM node points
• Number of document (documents)
• Number of registered event listeners (listeners)

For more information on how to locate memory leaks in memory analysis, see Zack Grossbart profiling with the Chrome DevTools

prove the existence of a problem

The first thing to do is to figure out some of the actions you think might lead to a memory leak. Can be any event that occurs on a page, mouse-over, click, or other interaction that may cause the page to degrade in performance.

Start recording on the timeline panel (ctrl+e or cmd+e) and do the action you want to test. You want to force the Trash bin icon () on the garbage collection point surface.

Here is an example of a memory leak where some points are not garbage collected:

If after some repeated tests you see jagged graphics (above the memory panel), there are many short-term objects in your program. If a series of actions does not keep memory in a certain range, and the number of DOM nodes is not returned to the beginning, you can suspect a memory leak.

Once you have identified a memory problem, you can use the heap profiler on the Analysis Panel (Profiles panel) to locate the source of the problem.

Example: Try a memory growth example that will help you effectively practice using the timeline to analyze the problems with your memories.

Memory Recycling

The memory collector (like V8) needs to be able to locate which objects are live (live), while those that are considered dead (garbage) are not referenced (unreachable).

If garbage collection (GC) is not able to reclaim garbage objects because of a logical error in JavaScript execution, the garbage objects can no longer be recycled. A situation like this will eventually make your application more and more slow.

For example, when you write code, some variables and event listeners are not available, but they are still referenced by some code. As long as the reference exists, the referenced object cannot be properly recycled by the GC.

When your application is running, some DOM objects may have been updated/removed, remember to check the variables referencing the DOM object and set it to null. Examine object properties that may be referenced to other objects (or other DOM elements). Keep your eyes on the variable cache that may be growing.

The heap analyzer took a snapshot

In the Profiles panel, select Take Heap Snapshot, and then click Start or press CMD + E or CTRL + E:

The snapshot was initially saved in the renderer process memory. They are imported into the devtools on demand, and you can see them when you click the snapshot button. When the snapshot is loaded into Devtools, the number below the snapshot caption shows the total memory of the (reachable) JavaScript object that can be referenced.

Example: Try the garbage collection in action example to monitor the use of memory in the timeline (Timeline) panel.

Clear Snapshot

By clicking the Clear All button icon (), you can erase all snapshots:

Note: Closing the Devtools window does not remove the collected snapshots from the rendered memory. When Devtools is reopened, the list of previous snapshots is still in.

Remember what we mentioned earlier, when you generate a snapshot you can force the GC to execute in Devtools. When we take a snapshot, the GC is executed automatically. You can easily perform garbage collection by tapping the Trash (garbage Collection) button () in the timeline (Timeline).

Example: Try scattered objects and analyze it with a heap analyzer (the heap Profiler). You can see the collection of items (objects).

Toggle Snapshot View

A snapshot can switch views based on different tasks. You can toggle through the selection box:

Here are three default views:

• Summary (summary) -The Display object is classified by the name of the construction function;
• Comparison (Control) -shows the difference of objects between two snapshots;
• Containment (Control) -can be used to detect heap contents;

The dominators view can be opened in the Settings panel – showing the Dominators tree. Can be used to find memory growth points.

Distinguish objects by different colors

The properties and property values of an object have different types and are automatically differentiated by Yan. Each property is one of the following four:

• A:property -The normal property of the index by name, referred to by the. (point) operator, or [] (brackets), such as ["Foo Bar"];
• 0:element -referenced by [] (brackets) through the normal properties of a numeric index;
• a:context var -a property within a function, within the context of a function, by name;
• A:system Prop -a property added by a JavaScript VM that the JavaScript code cannot access.

The named System object does not have a corresponding JavaScript type. They are built into the JavaScript VM object system. V8 places most of the built-in objects and user JS objects in the same heap. But they are just V8 's internal objects.

View Details Summary view (Summary view)

Opens a snapshot, which is displayed by default in a summary view, showing the total number of objects, which can be expanded to show specific content: Initially, a snapshot opens in the Summary view, displaying object totals, which CA n be expanded to show instances:

The first level is the "overall" row, which shows:

• The Constructor (constructor) represents all objects generated through the constructor
• The number of instances of the object is displayed on the Objects Count column
• The shallow size column shows the total number of shallow sizes (directly consuming memory) of the object generated by the corresponding constructor
• retained size column shows the maximum memory occupied by the corresponding object
• The Distance column shows the shortest distance the object reaches the GC root

When an overall row is expanded, all object instances are displayed. The direct consumption of memory and the total memory consumed by an instance are displayed accordingly. The number after the @ symbol does not have a unique ID for the object, and with it you can compare the objects individually in different snapshots.

Example: Try this example (open in the New Tab tab) to learn how to use the overview view.

Remember that the yellow object is referenced by JavaScript, and the red object is a node that is separated by a yellow background color reference.

Comparison view (control view)

This view is used to find the differences between snapshots against different snapshots to discover objects with memory leaks. To prove that an action on the application is not causing a leak (for example, a general pair of actions and undo actions, like finding a document and then closing it so that it does not cause a leak), you can try the following steps:

1. Take a snapshot of the heap before the operation;
2. Perform an action (do what you think will cause a leak);
3. Undo the previous action (the last action opposite, repeat several times);
4. Take the second snapshot, switch the view into a contrasting view, and compare it to snapshot 1.

In the control view, the difference between the two snapshots is displayed. When a general category is expanded, objects that have been added and deleted are displayed:

Example: Try an example (opens in a new Tab tab) to learn how to use a control view to locate a memory leak.

Containment view (control view)

The control view can be called a bird's eye view (bird ' Eys view) of the object structure of your app. It allows you to look inside the function and watch the VM's internal objects just like your JavaScript object, allowing you to use the memory at a very low level in your app.

The view provides several entry points:

• Domwindow Objects -These objects are "global" objects of JavaScript code;
• GC Root -The real GC root of the VM's garbage collector;
• native Objects -browser objects are automatically manipulated in a "push" javascript virtual machine, such as DOM nodes, CSS rules (the next section is described in detail.) )

is a typical control view:

Example: Try an example (opens in a new Tab tab) to learn how to use control view to view closures inside and event handling.

Recommendations for closures

Naming a function can help you make a distinction between closure functions in a snapshot. For example, the function is not named in the following examples:

function Createlargeclosure () {  var largestr = new Array (1000000). Join (' x ');  var LC = function () {//This is a named function    return largestr;  };  return LC;}

And the following one gives the function a name:

function Createlargeclosure () {  var largestr = new Array (1000000). Join (' x ');  var LC = function LC () {//This is a named function    return largestr;  };  return LC;}

Example: Try This example why eval is evil to analyze the effects of closures in memory. You may also be interested in trying the following example to record heap allocations (heap allocation).

Exposing DOM memory leaks

A unique aspect of this tool is the presentation of bidirectional references between browser-native objects (DOM nodes, CSS rules) and JavaScript objects. This can help you discover the hard-to-find memory leaks caused by forgetting to dereference the free DOM subnodes.

Dom memory leaks may be beyond your imagination. Take a look at the following example – #tree对象什么时候被GC呢?

var select = Document.queryselector;  var treeref = Select ("#tree");  var leafref = Select ("#leaf");  var BODY = Select ("Body");  Body.removechild (treeref);  #tree can ' t is GC yet due to treeref  treeref = null;  #tree can ' t is GC yet due to indirect  //reference from leafref  leafref = null;  #NOW can #tree GC

#leafRepresents a reference to its parent node (parentnode), which recursively references it #tree , so that only the #tree entire tree structure represented after Leafref is nullified will be recycled by GC.

Example: Try leaking DOM nodes to see where the DOM node is leaking memory and how to locate it. You can also take a look at this example: DOM leaks being bigger than expected.

View Gonzalo Ruiz de Villa articles finding and debugging memory leaks with the Chrome devtools to read more on the basics of DOM memory leaks and analysis.

Native objects are easier to find in summary and containment – with their specialized categories:

Example: Try this example (open in the New Tab tab) to learn how to detach the DOM tree.

View of the dominant person (Dominators views)

The dominant view shows the tree of the dominator of the heap graph. The dominant view is much like the control (containment) view, but has no attribute name. This is because the dominant person may be an object that is not directly referenced, that is, the dominant tree is not the build tree of the heap graph. But this is a useful view to help us quickly locate the memory growth point.

Note: In Chrome Canary, the Dominator view is enabled in Devtools Settings > Show advanced Heap Snapshot properties, and the restart Devtools takes effect.

Example: Try this example (opens in a new tab tab) to practice how to find memory growth points. You can further try the next example retaining paths and Dominators.

Object Assignment Tracker

The Object Tracker consolidates the snapshot incremental update analysis of the heap Profiler and the records of the timeline panel. As with other tools, the heap configuration of a recording object requires a record to be started, a sequence of operations to be performed, and then a record is stopped and analyzed.

Object Tracker keeps a snapshot of the heap (frequency reaches every 50 milliseconds!) ) to record the last snapshot at the end. The heap allocation analyzer shows where the object is created and locates its reserved path.

Turn on and use the Object Analyzer

Start using Object Analyzer: 1. Make sure you're using the latest version of Chrome Canary.

1. Open the Devetools and click on the gear icon (translator: No idea what this step is for).
2. Now, open the profiler panel and you'll see the option "Record Heap allocations".

The bar above represents a new object that is generated in the heap. The height corresponds to the size of the corresponding object, and its color indicates whether the object is still in the last snapshot: The blue bar indicates that the object is still in the timeline, and the gray bar indicates that the object was generated in timeline, but it has been recycled by memory before the end.

In the example above, an action was performed 10 times. The same program retains 5 objects, so the last 5 blue bars are preserved. But there is a potential problem with the last column left. You can use the slider bar on the timeline to narrow down to that particular snapshot and find the assigned object.

Clicking on an object in a heap will show its total reserved memory tree in the lower part of the heap snapshot. Checking this object's reserved total memory tree gives you enough information to understand why the object is not recycled, and then you can modify the code to remove unnecessary references.

Memory Analysis FAQ

Q: I can't see all the properties of an object, and I also see their non-string values! Why?

Not all properties are fully stored in the JavaScript heap. Some of these are obtained by executing the getters method of native code. These properties are not captured in the heap snapshot, to prevent calls to the getters method and to avoid changes in the state of the program if these getters methods are not "pure" functions. Similarly, non-string values, such as numbers, are not captured to reduce the size of the snapshot.

Q: What does the number after the @ sign mean – An address or an ID? Is this ID value really unique?

This is the object ID. The address of the display object is meaningless because an object is removed when it is garbage collected. These object IDs are true ids– that is, they are the only representations between different snapshots. This allows for a precise comparison between the heap states. Maintaining these IDs adds additional expense to the GC process, but this is only allocated when the first heap snapshot is recorded – there is no additional expense if the heap analyzer is not used.

Q: Are the "dead" (unreferenced) objects included in the snapshot?

No, only objects that can be referenced are displayed in the snapshot. Also, the GC operation is performed automatically before taking a snapshot.

Note: When writing this article, we plan to stop the GC when we take a snapshot and prevent the heap size from being reduced. This is now the case, but the junk object still appears outside the snapshot.

Q: What is the GC root made of?

is made up of many parts:

• Native object graph;
• Symbol table;
• The stack in the VM thread;
• Edit the cache;
• The controller context;
• The global controller.

Q: I learned that I could use the heap profiler and the timeline memory view to detect leaks. But which tool should I use first?

The timeline version is the first time you use your page to find that the speed is slowing down to judge too much memory usage. Slowing down your site is a typical memory leak, but it can be another reason – there may be a bottleneck in rendering or network transmission, so be sure to address the real problem with your Web page.

If the argument is a memory issue, open the Timeline panel and the memory label. Click the Record button, and then repeat the action on your app several times that you think might cause a memory leak. Stop recording. The memory usage diagram of your application is generated. If the use of memory has been growing (without a corresponding drop), this indicates that your application may have a memory leak.

Generally a normal application of memory usage graphics is jagged, because memory is used and then recycled by the garbage collector. No need to worry about this zigzag – because JavaScript always consumes memory, and even an empty one requestAnimationFrame can cause this jagged shape, which is unavoidable. As long as it's not the kind of shape that's allocating a lot of memory, that's a lot of memory garbage.

The growth line is a need for your vigilance. The DOM node Counter,document counter and event listener count in the memory tag are also useful for diagnostic analysis. The number of DOM nodes that are used by native memory does not affect JavaScript memory graphs.

Once you confirm that your application has a memory leak, the heap analyzer can be used to find a memory leak somewhere.

Q: I find that the number of DOM nodes in a heap snapshot is marked as "Detached dom tree" in red, and the others are yellow, what does that mean?

You will find that there are different colors. Red nodes (with dark backgrounds) do not have direct references from JavaScript to them, but they are part of the detached DOM structure, so they remain in memory. It is possible that a node is referenced by JavaScript (possibly in a closure or a variable), which prevents the entire DOM tree from being reclaimed by memory.

The yellow node (yellow background) has a direct reference to JavaScript. Look at a yellow node in the same detached DOM tree to locate your JavaScript reference. You might see a chain of attribute references (for example:) from Dom window to that node window.foo.bar[2].baz .

The following dynamic diagram shows the process of separating the nodes:

Example : Try This example detached nodes you can view the node's life cycle in timeline and then take a snapshot of the heap to find the detached node.

Q: What is the difference between directly consuming memory (shallow size) and occupying total memory (retained size)?

Thus, an object can exist in memory in two ways (be alive)-a direct one that is reserved for an accessible (Alive) object (the window and document objects are always accessible) or a packet-left reference that is implied by the native object (like a DOM object). In the latter way, it is possible to prevent the object from being automatically reclaimed by GC, and to have the potential to drain the leak with the guided memory. The memory occupied by the object itself is called direct memory consumption (typically, arrays and strings retain more direct memory (shallow size)).

An object of any size can be reused by preventing other object memory from being recycled in large memory. When an object is deleted (it causes some dependencies that cannot be referenced) the amount of memory that can be freed is said to occupy the total memory (retained size).

Q: There is a lot of data under the constructor and retained fields. Where should I start investigating? Have you encountered a memory leak?

In general it is best to start with the first object sorted by retainers, and retainers is sorted by distance (that is, the distance to the Window object).

The shortest distance object may be the preferred object that may cause a memory leak.

Q: What is the difference between Summary, Comparison, Dominators, and containment these views?

You can experience their differences by switching views.

• The Summary (summary) view helps you find objects (and the memory usage of objects) by grouping them into constructors. This view is useful for finding DOM memory leaks.
• The Comparison (Control) view is able to search for memory leaks by showing which object memory is properly reclaimed. A snapshot of two (or more) memory usage is typically logged before and after an operation. It is to see if there is a memory leak by looking at the amount of memory released and the number of references, and find out why.
• The containment (Control) view provides a better display of the object structure, helping us to analyze object references in global scopes such as window to find out what holds those objects. It allows you to analyze closures and drill down into the deeper layers of the object to see.
• The Dominators view can be used to help us confirm that no unwanted objects are still hanging in a certain location (such as those that are referenced), and that the deletion/garbage collection of the object is really playing a role.

Q: What does the constructor (a set of) content in a heap analyzer represent?

The
• (global property)  -The intermediate object between the global object (like ' window ') and the object referencing it. If an object is generated by a constructor person and referenced by a global object, then the reference path is this: [Global] > (global) > Person. This is not the same as the normal direct reference to each other's objects. We use intermediate objects for performance reasons, global object changes are very frequent, and the property access optimizations of non-global variables do not apply to global variables. The contents of roots in
• (Roots)  -constructor refer to the object it is selected. They can also be references that are created autonomously by the engine. This engine has caches for referencing objects, but these references do not prevent reference objects from being recycled, so they are not really strong references (FIXME).
•   (closure)  -A reference to a set of objects in a function closure
• (array, string, number, regexp)  -a set of properties that reference the object type of a array,string,number or regular expression
• (compiled code)  -simply, Everything is related to compoled code. Script is like a function, but it actually corresponds to the <script> content. Sharedfunctioninfos (SFI) is the object between the function and compiled code. Functions usually have content, while Sfis does not (FIXME).
•   htmldivelement ,    htmlanchorelement ,   DocumentFragment   etc – a reference to a elements or Document object in your code.

Many other objects generated in the life cycle of your program, including event listeners or custom objects, can be found in the following controllers:

Q: Do I need to turn off any features in chrome that might be impacted when I do memory analysis?

We recommend that when doing memory analysis with chrome devtools, you can use Incognito mode that turns off all extensions, or set the user folder to ( --user-data-dir="" ) before you open chrome.

Applications, extensions, and even records in the console can have a potential impact on your analysis, so if you want your analysis to be reliable, disable it.

Written in the last words

Today's JavaScript engine has a strong ability to automatically reclaim the memory garbage generated by the code. That is, they can only do this, but our application is still proving to be a memory leak due to a logical error. Use the appropriate tools to find the application's bottleneck, and remember, don't rely on guessing – test it.

Help instances diagnose memory leaks

Although a lot of the content has been mentioned in this article, a series of examples of testing memory-related problems are useful, and here is an example of a set of DOM node memory leaks. You may want to experiment with these examples before testing your more complex pages or applications.

• Example 1:growing Memory
• Example 2:garbage Collection in action
• Example 3:scattered Objects
• Example 4:detached Nodes
• Example 5:memory and Hidden classes
• Example 6:leaking DOM Nodes
• Example 7:eval is evil (almost always)
• Example 8:recording Heap Allocations
• Example 9:dom leaks bigger than expected
• Example 10:retaining Path
• Example 11:last Exercise

JavaScript memory analytics for Chrome developer tools