[Webkit-unassigned] [Bug 53659] Web Inspector: Better support for finding "leaked" DOM

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=53659





--- Comment #4 from Mikhail Naganov <mnaganov at chromium.org>  2011-02-04 10:03:52 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Can you please provide more info about the caching system (or provide me with source code pointers privately): what the caching system does? If a node is either in cache or in page's DOM tree, it should be never collected, right? So apparently there is some scenario for nodes disposal.
> > 
> > I've added eae who might be able to explain a little better. But as a simplistic example, imagine a fixed size array where each item points to a DOM node that is no longer attached to the document. As new nodes are added to the front of the array, old nodes are pushed out the end. The app expects that the ones pushed out the end are collected. However, there is some other piece of code (other than the caching array) which has a reference to the node and is preventing its collection. But given the size of the codebase it is difficult to pinpoint what other piece of code is holding the reference alive.
> 
> Just in case, if detached nodes form tree of its own (traversable via parent, children, sibling), they are treated as an object group and therefore should be eligible to GC in the same time, so retainers could be objects in the cache itself.  If it's not impossible, I'd suggest you to trace object grouping as well.
> 
> BTW, Mikhail should be able to explain it in more details, but I think he has this feature---list all the retainers of the object---in the heap profiler, at least in experimental variant.  BTW, Mikhail, do your retainer thing supports tracing object groups?
> 

I see that I need to include object groups on par with VM GC roots, as they can also prevent objects from deletion.

> > 
> > > 
> > > For the new heap profiler (see https://bugs.webkit.org/show_bug.cgi?id=50510) I maintain a map of unique object IDs for heap contents that help to track objects lifetime. Will this help you?
> > 
> > It sounds like the same problem, but I from the description in the bug, I don't fully understand the new feature.
> 
> There was a confusion over term 'id'.  You meant HTML element's id while we rather thought of JS object identity.  Mikhail's ids are unique ids for the whole life of JS objects (that's trickier than plain pointer as GC can move objects).  So if you'd like to trace the life of the object, your best bet is Mikhail's ids.
>
> > 
> > > 
> > > Some questions:
> > >  - by 'id of the element' do you mean DOM nodes implementation (C++) object addresses, or what?
> > 
> > The DOM node's id.
> > <div id=foo></div>
> > I know this may seem awkward because it isn't always available, but when it is available it is the key piece of information that could help a web app developer understand which node this is.
> >

OK, got it. Although, no data from DOM nodes is stored in VM's heap, I think it is possible to retrieve it during heap sampling.

> > >  - how can I know that a DOM node is held only from VM -- by verifying that refcount == 1?
> > 
> > I'm not very familiar with how GC works, but Jamesr give me a quick overview. Perhaps we can consider it help only from the VM if the object groups's refcount is equal to the number of JS references.
> 
> Object groups have no refcounts at all (and nothing in V8 is ref count).  There are several complications.  For example, JS objects can be retained not only by pure JS references, but by various types of C++ handles (these are counterparts of JS references in C++ land).
> 
> It might be a good experiment to check how many JS wrapped objects have refcount 1 (when you wrap an object, you ref it), it might indeed reveal some leaks.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.