Heap Profile - retaining tree shows outdated / gc'd path?

[mistaecko]

I am confused by an object's retaining tree that displays what is seems an 'outdated' path (that has been already gc'd.)

All the nodes leading to one element before the selected element (see screenshot) show "Preview is not available" on hover. The first object that can be expected is actually missing the reference to the object that supposedly establishes the retaining path (in the screenshot: "cache" does not have a property "textfield-make-1458-inputEl".

That result is quite confusing to me. Is this a bug or a possible/expected behavior?

Note: I am memory profiling an application using three consecutive snapshots, and displaying objects on snapshot 3 that were allocated between snapshot 1 and 2. Chrome 34.0.1847.131 m. 

Any hints appreciated. Thank you!

mistaecko

[Ilya Tikhonovsky]

Snapshot shows you the state of the heap for the moment when it was taken, so some objects might have been collected/changed by the time when you try to look at them. In this case Profiler wouldn't be able to show you the 'real' object.

BTW It might be more interesting to use our new Record Heap Allocation snapshot type. 

--
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-developer-tools+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/58cffe0b-dcfa-4393-9fa1-fa72fc3046a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Samuel Ecko]

Thx for your reply!

It's still not totally clear to me what is going on. May I ask two short follow-up questions?

Considering that I use the described technique (with 3 snapshots), do I see the **retaining tree** at the time of snapshot 1, 2, or 3? I would have thought that I see a subset of the state of snapshot 3 in terms of which heap objects are being filtered - my understanding is that this filtering should not affect the retaining tree at all once a heap object 'qualifies' (=has been created between snapshot 1 and 2).

The inspection result in the tooltip, does that represent the **object state** at the time the snapshot 3 was taken, or the current heap state at the time of inspection?

I am aware of the "Record Heap Allocations" profile, but it would be VERY helpful for me if you could answer my follow-up questions - I have been wondering about this for quite some time and have difficulties finding resources on DevTool's memory profiling that explain these details.

Thank you so much!

mistaecko

--
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/OyNuoa4Ep64/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/CAD74ZUAHXpuCVc1FxeSGXtgUVdAZ0rbPBmVECMgmvJya3JLAbw%40mail.gmail.com.

[Ilya Tikhonovsky]

When you use 3 snapshots technique you need to select the latest snapshot and you will see the state of the heap that was recorded in it.

Actually when you press Take Snapshot button, the profiler iterates through all heap objects and assigns an id to the each object which it sees the first time. (it also makes snapshot and send it to the frontend) So the objects in the first snapshot will get ids from 1 to n1, the new objects that were found when you took the second snapshot would get ids from n1+1 to n2, the objects that were alive since the first snapshot would keep their ids.

When you see the third snapshot we can use max seen object ids of two previous snapshots and filter out the objects that have ids not in range n1 - n2. That is how this filter works.

When you hover the mouse over an item in the snapshot, the profiler gets its id and ask backend about the object with this id.

Unfortunately it might happens that the page has done something since last snapshot and has removed a property of an object and has forced gc for some reason. As a result the backend part of the profiler may have no chance to resolve this id into a live object.

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/CAMuqKaV0cS5a32%3Dy08MVSpr2NLZkHSVVWkeNYFwxkw1q1p_zDw%40mail.gmail.com.

[Samuel Ecko]

Thx, that makes things a bit more clear!

You are saying that object inspection (the tooltip) is done on 'live' data, that is on the 'current' heap, and thus may show objects in a different state than at the time of the snapshot. That makes sense and I could easily observe this behavior doing a simple experiment. 

I also observed that the object's property as displayed **inside** the "Constructor" tree always reflects the state from when the snapshot was taken. It is apparently part of the data taken with the snapshot.

I also verified that the retaining tree is generated when the snapshot is created, and will remain unmodified as well.

Thanks again for your time!

mistaecko