[Webkit-unassigned] [Bug 28819] Heap profiler: showing retainers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Oct 3 16:25:06 PDT 2009


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





--- Comment #3 from Timothy Hatcher <timothy at hatcher.name>  2009-10-03 16:25:06 PDT ---
(In reply to comment #2)
> Created an attachment (id=39637)
 --> (https://bugs.webkit.org/attachment.cgi?id=39637) [details]
> Update version of UI
> 
> I re-thinked about retainers, and experimented with real web apps. This
> radically changed my mind. I discovered that it is possible to put retainers
> graph into every snapshot in a reduced form. That is, retainments are tracked
> not for individual objects but rather for objects constructed with the same
> function. The only problem here is with anonymous Object and Array instances.
> For them, initially we consider every instance, but then we are aggregating
> them by similarity of their backreferences (in short, if two Object instances
> are held by instances of the same constructor, they are considered equivalent.)
> 
> Thus, we don't need an additional pane, and instead can show retainers
> naturally in the heap snapshot. To help a developer to prioritize back
> references, we should show how many object instances are retained for every
> backreference (e.g. objects of 'baz' constructor can be held by 'foo' and
> 'bar', of which 'foo' holds 90% of objects and 'bar' only 10%). I don't think
> we need to display the number of retained objects for next levels, because it's
> expensive to count them. Also I'm not sure whether we always could display
> deltas: it seems OK for named constructors, but for Objects and Arrays it's
> hard to find corresponding entries in two snapshots (we can't even use real
> memory addresses, because objects may get moved during GC.)

I like this approch! I assume "bar-retainer" is the name of the object (not you
adding "-retainer" to it?

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



More information about the webkit-unassigned mailing list