From 08da4e256524f9e06453b35994aa2e734d2d9168 Mon Sep 17 00:00:00 2001 From: Patrick Mueller Date: Mon, 28 Sep 2015 17:24:10 -0400 Subject: [PATCH] added 2015-09-25 meeting notes --- wg-meetings/2015-09-25.md | 154 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 wg-meetings/2015-09-25.md diff --git a/wg-meetings/2015-09-25.md b/wg-meetings/2015-09-25.md new file mode 100644 index 0000000..09e36af --- /dev/null +++ b/wg-meetings/2015-09-25.md @@ -0,0 +1,154 @@ +# September 25th 2015 + +* [YouTube recording](https://www.youtube.com/watch?v=yM6q92V1IDk) +* [Hangouts Event](https://plus.google.com/events/ceccr8614j3pg3rsqcq6ev4fsik) +* [issue for this meeting](https://github.com/nodejs/tracing-wg/issues/21) +* [previous meeting](https://github.com/nodejs/tracing-wg/blob/master/wg-meetings/2015-02-19.md) - 2015-02-19 + +# 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](https://github.com/nodejs/tracing-wg/issues/21#issuecomment-142727693), + 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](https://github.com/nodejs/tracing-wg/issues/21#issuecomment-142747845), + he asks about the nodejs/node issue + [Inspecting Node.js with Chrome](https://github.com/nodejs/node/issues/2546), + and how yury-s’s work might fit in. + + +* in the last Tracing WG meeting - + [2015-02-19](https://github.com/nodejs/tracing-wg/blob/master/wg-meetings/2015-02-19.md), + 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](https://youtu.be/yM6q92V1IDk?t=258) - +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](https://youtu.be/yM6q92V1IDk?t=582) - +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](https://github.com/nodejs/tracing-wg), 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](https://github.com/nodejs/tracing-wg/issues/22) has been created +for this topic. + +## Status of AsyncWrap + +[16:48](https://youtu.be/yM6q92V1IDk?t=1008) - +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](https://youtu.be/yM6q92V1IDk?t=1197) - +Stephen wanted to make sure that the effort around +[making Chrome Dev Tools more amenable to Node.js](https://github.com/nodejs/node/issues/2546) +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](https://github.com/nodejs/post-mortem) 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](https://youtu.be/yM6q92V1IDk?t=1628) - +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.