Skip to content

Latest commit

 

History

History
154 lines (114 loc) · 6.44 KB

2015-09-25.md

File metadata and controls

154 lines (114 loc) · 6.44 KB

September 25th 2015

Attendees

  • @pmuellr - Patrick Mueller
  • @Qard - Stephen Belanger
  • @yunongx - Yunong J Xiao
  • @matthewloring - Matt Loring
  • @AndreasMadsen - Andreas Madsen
  • @ofrobots - Ali Sheikh
  • @brycebaril - Bryce Baril
  • @thlorenz - Thorsten Lorenz
  • @natduca - Nat Duca

Agenda

  • Set some cadence for these meetings. How often? Every month? Twice a month? Is there a good standard time? Is today’s call (8am US Pacific) good?

  • Break down components (async_wrap, pulling dev tools out of blink, generic native tracing, perf events) into smaller parts and define what work actually needs to be done to make progress. Some text and diagrams of how the various components interact would be useful. For anything that’s an API, some doc on the API - eg, as a strawman - would be useful.

  • in Trevor’s comment, he notes “I haven't done much with AsyncWrap for a while because this is the type of conversation I wanted to have before proceeding. When should events be fires, in what order, etc. are things that need to be discussed.” Unfortunately, Trevor is unlikely to be on this call to have a discussion - should cue up for next call, but if anyone has any other thoughts during this call, please chime in.

  • in Qard’s comment, he asks about the nodejs/node issue Inspecting Node.js with Chrome, and how yury-s’s work might fit in.

  • in the last Tracing WG meeting - 2015-02-19, there was lots of discussion around the v8-trace work ongoing at Google. Mentions of reference implementations coming, etc. Would be good to have an update on the current status

Minutes

Monthly meeting cadence?

4:18 - Patrick suggested monthly meetings. Nat suggested that we might want to talk more frequently.

Looking back at the video, it appears Nat joined the call and for some reason the video played back Patrick suggesting "having meetings more often" - but the context of that quote was Patrick suggesting having meetings more often than every seven months (it's been seven months since the previous call). So, doesn't really seem that there's anyone actually suggesting meetings more often than once a month.

But since no one seemed to have an issue with another meeting in two weeks, let's give it a go!

Ali suggested was to use doodle to schedule the meeting. Patrick will work with Ali and Matt to schedule the next call using doodle.

Break down components into smaller parts

9:41 - Patrick suggested creating text and diagrams, description of potential APIs that could be put in a single location, rather than scattered throughout the WG minutes. Andreas, Yunong agreed.

Patrick suggested adding a new documents directory in the tracing-wg repo, where we can create documents/directories per component.

Suggested components:

  • AsyncWrap
  • v8-trace
  • platform-specific tracing (DTrace, LTTng, ETW)
  • perf-events (from Yunong)

Issue 22 has been created for this topic.

Status of AsyncWrap

16:48 - Trevor Norris wasn't able to attend, but as there is interest here from several parties, make sure to queue this up for a future call.

Andreas provided some quick background on current state of AsyncWrap.

Issue w/tracing and inspecting node.js with Chrome

19:57 - Stephen wanted to make sure that the effort around making Chrome Dev Tools more amenable to Node.js is moving forward, since it may serve as a good way to deliver tracing capability to customers. There doesn't seem to be anything in the tracing space that would be a blocker here.

Patrick asked whether there was a Debug WG? Answer is no, but there is this WG that looks at debugging things, as well as the Postmortem WG Thorsten also mentioned debugging with gdb, mdb, etc. Where would that fit in? Patrick mentioned he'd noodle on this, and chat with some folks to see if it makes sense to add more workgroups.

Status of v8 tracing

27:08 - Nat provided some status on v8 tracing. As I'm fairly unfamiliar with v8 tracing, please refer to the video for the real truth. Nat and Ali did most of the talking here.

Google has been focusing on handing sampling data, getting that into the trace pipeline. They are recreating the CPU profiling view in Chrome Dev Tools with the new trace system. Close to switching from old way it was done. V8 spits out trace events when functions are created/moved, etc. Sampling profiler just collects the stack (incl/function pointers), and then this data is stitched together in the tool.

Yuong asks how you could use this in Node.js. Nat mentions that the sampling glue is outside of VM, sits in the embedding space - eg, Chrome or in our case, Node. Chrome code should be easy to copy. Nat mentions trying to get all the nice diagnostic tools to feed into one pipe. This allows cross-referencing with other tools, sharing structural data.

Questions about performance, questions about the how this could be done in node, etc.

Question asked about the whether the existing cpu profiling functions for Node are affected. As there are many places profiling data is available in node today, need to get more precision on the question.

Nat brought up structural tracing. For instance, providing parsing and compilation statistics in the tracing stream. Not available yet. Promise dependencies and other internal v8 things that need diagnostic information, could also make use of this.

Nat also mentioned providing more context in the trace stream; for Chrome this might be frame/tab, for Node this would be isolates.