Heap Profiler Oddity

[mistaecko]

In the following heap snapshot, I don't understand why the object is not garbage collected?

The retaining tree shows only references to execution contexts. These go back to generated anonymous functions that create a closure over the object as 'scope', and the resulting functions were then assigned as object members. The concept is more or less that of ES6 Function.bind, just non-native (from the ExtJs framework). 

While the screenshot is truncated at the bottom, I guarantee that the all retaining paths follow exactly the same structure as the ones shown.

https://twitter.com/mistaecko/status/466262731167780865/photo/1

Any feedback appreciated! Thank you!

mistaecko

[Alexei Filippov]

Hi mistaeco,

Try enabling Show advanced heap snapshot properties in DevTools general options (gear button). It should then be able to show the full retaining path. Note that you have to retake or save-and-reload the snapshot after changing the option.

Best,
Alexei

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/31d1f4fd-26ee-4b66-b4c6-aaa5d6828d72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Samuel Ecko]

Alexei,

thx for that hint. The advanced heap properties don't give me much more insight though, most likely because I know only little about V8s internal structures. The concept of storing execution contexts ('system / Context') is where it ends for me. 

Not sure why the retaining tree leads back to "initial_map" in the original constructor function (Xoox()).

I should maybe add that the constructor function is created using an indirect eval() call in order to allow for named constructors (this is ExtJs which uses a factory method for classes). 

Maybe the following screenshots make any sense to you. All of them are taken with the latest Canary version 37.0.1991.1 canary. One a01 is taken after only one iteration of the action that creates and then destroys the 'XooX' object. a02 is taken after several iterations. 
It should be noted that it does NOT appear to be a genuine memory leak, since object instances do not add up over time and will be gc'ed at some point (even though I observed two instances at one point). 

I was surprised though to see the object remain in memory also with JS optimizations disabled (--js-flags="--nocrankshaft --nouse-ic" ) but maybe these switches are outdated (see "noopt" screenshot).

I am still unsure if I should just accept the fact that the object is not being garbage collected immediately and attribute that behavior to V8 internals (maybe internal optimizations), or if I should try to dig deeper (resources seem scarce in regards to this)  - could it be a bug?

It definitely makes hunting leaks more difficult if these objects remain on the heap and are shown in the snapshot.

Cheers,

Sam

--
You received this message because you are subscribed to a topic in the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-chrome-developer-tools/QYi0Zj46gIQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-chrome-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CACHCMCeBtU63R3C%2BkawdfLTvxhdD346Lg1LZwH8Nq1HZnrnusA%40mail.gmail.com.

[Alexei Filippov]

AFAIK maps referenced from a transition array are considered as weak, so e.g. @529883 from the third screenshot should have been garbage collected. Could v8 folks please take a look.

+v8-dev

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/CAMuqKaXPughD3VR9EVbSyt%3D9BeijFEQ-e6-BHPg9SQYS4a09qQ%40mail.gmail.com.