[Webkit-unassigned] [Bug 55794] Web Inspector: Need new graphic icon for garbage collect button

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Pavel Feldman <pfeldman at chromium.org>  2011-03-07 03:20:37 PST ---
(In reply to comment #6)
> The object counters are a useful tool -- the ones that I've found the most useful when diagnosing mem leaks in webkit are
> 
> 
> - Node -- catches JS errors where DOM Nodes are increasingly created
> 
> - EventListener -- catches cases where JS code keeps adding event listeners to nodes. Also provides a starting point to analyze closures that may be keeping bits around via JS heap graph.
> 
> - Document -- ref counting bugs will eventually cause these to stick around. This one is useful to C++ devleopers but probably not JS folks since there should not be an ability for JS code to cause this to happen. However it still is useful and revealing to see how long these Document instances can stick around usually due to GC and JS/webcore binding behavior.

One can surely hold many documents from within javascript via say element's style property, so I think this is useful for JavaScript developers as well.

I look at Node::dumpStatistics (http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/dom/Node.cpp&q=Node.h&exact_package=chromium&d=6&l=135) and I don't see why we can't move most of its goodness from behind the flag. Putting static counters into various kinds of nodes should not be expensive. We could also keep track of the number of attached nodes via tracking setDocument. Not a strict requirement - they are anyways reachable and hence countable, but seeing detached DOM numbers is handy and is also inexpensive.

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