[Webkit-unassigned] [Bug 107673] Web Inspector: More insight into GC pauses

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jan 31 05:18:22 PST 2013


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





--- Comment #2 from Yury Semikhatsky <yurys at chromium.org>  2013-01-31 05:20:23 PST ---
(In reply to comment #0)
> Is there any way we can understand which parts of the developer's code are causing a lot of temporary allocations? That is, stats about which objects created by the developer were picked up in GC?

Can you elaborate on what do you mean by picked up in GC? Is it about the objects that survive scavenge pass? Or is it a set of objects that were unreachable during the pass?


(In reply to comment #1)
> More context:
> 
> At present we have GC records showing in the timeline, which is great. What it doesn't tell you is what was picked up in GC, specifically that which relates back to your code. So if you're using a lot of temporary variables or anonymous functions somewhere in your code it is very difficult to find, especially if you have a large codebase. A suggestion here might be to in some way track the allocations so that you can see the top scoring items. So in effect if a developer is looping through an array and effectively assigning the same logical function as a callback then we can point at that to say "this function is being allocated a lot".

So if we show the heap stats at point A and then at point B. Do you mean at point B in addition to total js heap size we should show how many object that were alive at point A and survived at point B + number of objects that were allocated between A and B and still alive at the point B? Or do you also see how many objects were collected since point A?

-- 
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