[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