[Webkit-unassigned] [Bug 37025] Web Inspector: GC Run event should be added to Timeline Panel

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Apr 4 06:51:37 PDT 2010


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





--- Comment #11 from Pavel Feldman <pfeldman at chromium.org>  2010-04-04 06:51:37 PST ---
(In reply to comment #10)

> The users will see standard popups without Heap Size info. Also GC Run event
> will not appear until somebody write an implementation of these methods for
> JSC. The usedHeapSize/totalHeapSize properties at frontend side are defined but
> zero in JSC case.
>

Ok, sounds reasonable.

> It is not possible to call TimelineAgent from GC directly but I can push GCRun
> events to the agent 
> each time when agent ask GCEventHelper about HeapSize info.
> In case of pull design scheme, the agent will have to know about internal
> structure of GCEventHelper.
> 

It does not need to know about internal structure of GCEvenHelper in case you
expose a GCRecord struct and return a vector of these in getGCRunRecords.

> As far as GC run is happening more or less randomly I'm trying to push gc
> events into to timeline each time when TimelineAgent is called via will or did
> methods.
> It is enough to do that at pushCurrentRecord and addRecordToTimeline but some
> events like SendRequest are propagating event record to the frontend directly.
> 

That's what I a talking about - there is no single place in the code that would
allow  adding an instrumentation flavor (such as memory state) to each of the
records. There should be a single generic method every record is going through,
so that you could put your heap snapshotting there. Single place.

> I think it is not so many chances to use JSC and V8 at the some time and there
> is no special reason to have an abstract class and implementation with virtual
> functions.
> 

That's not about it. That's about knowing when you break v8 while editing jsc
and such.

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