Skip to content

Latest commit

 

History

History
199 lines (139 loc) · 7.88 KB

2015-10-07.md

File metadata and controls

199 lines (139 loc) · 7.88 KB

October 7th 2015

Attendees

  • @yunongx - Yunong J Xiao
  • @trevnorris - Trevor Norris
  • @thlorenz - Thorsten Lorenz
  • @watson - Thomas Watson Steen
  • @Qard - Stephen Belanger
  • @pmuellr - Patrick Mueller
  • @lucamaraschi - Luca Maraschi
  • @bnoordhuis - Ben Noordhuis
  • @AndreasMadsen - Andreas Madsen
  • @matthewloring - Matt Loring
  • @ofrobots - Ali Sheikh
  • @fmeawad - Fadi Meawad

Agenda

  • More info on v8 tracing - Ali?

    • Will CPU profiling API deps/v8/include/v8-profiler.h go away?
    • Specific code pieces we will need to implement for node?
    • Will v8 source trace events be included, that we can then redefine the macros for our the node impl?
    • Link to stand-alone version of chrome://tracing: https://github.com/catapult-project/catapult/tree/master/tracing

  • Status on AsyncWrap - Trevor Norris

  • Status on docs for components - Patrick Mueller

  • Break things down into smaller steps that people with time can do to move things forward. (V8 tracing and AsyncWrap)

Minutes

v8-tracing

5:12 - Ali

  • some details posted by Ali after last meeting - in issue 21 and in docs/v8-tracing

    • Fadi has been working on getting Chrome tracing bits into v8

      • trace events are associated with a category, which is enabled for trace or not

      • trace events are written to a collector

    • New tracing bits boil down to 3-4 methods a v8 embedder (eg, Node.js) needs to implement

      • check if a category is enabled or not
      • add a trace event
      • update trace event
      • add a new category

      Once enabled, these methods will start getting invoked coming in through the add trace event method.

      v8 needs to work on adding per-isolate support to tracing

Presumably we want to take advantage of this in Node.js? v8 will already be spitting out v8-specific events which will likely be of interest to Node.js devs, and the tracing infrastructure is general enough for Node.js to use it as it's tracing platform - so yes.

What kind of tooling is available for reading trace output? Tracing JSON output can be loaded in chrome://tracing

JSON format is very well defined; there is a binary format as well, but the JSON format is presumably easier to tool around.

Can you stream data into chrome://tracing? No.

Tracing has minimal overhead. C++ intf is defined in macros, add event method should return very quickly (queue message and then return). Only events matching selected categories are emitted.

Continuously record trace data? Sure, stream trace data to analyzer.

Issues about size of trace data? 200MB of trace data can be compressed into 8-16MB, using gzip.

Node.js will be responsible for dealing with the tracing data being generated. We need to decide what the implementation will be - write to a buffer, write that to a file from a separate thread, expose a stream to Node.js user? New command-line arguments for node to indicate where the trace data goes, how it's collected.

Identify use cases: continuous streaming; stream to a file? Hopefully we can determine the shape of a single tracing framework for everyone. Try to avoid fragmenting all the use cases across different modules.

Will v8's current deps/v8/include/v8-profiler.h CPU profiling go away soon? No. At least not yet. Function we will need to replace once v8's CPU profiling goes away (if it does) can be copied from older v8 and Chrome anyway. Ben also noted that StrongLoop as a proprietary CPU profiler which they may considering open sourcing, if required.

On demand tracing? Turn categories on/off dynamically? Currently categories are cached in macros, so dynamic setting of them not currently possible. However, low overhead capability of turning off tracing, reconfiguring a new set of categories, and starting a new trace is available. Will need to implement this as Node.js functionalities.

Good trace points for Node.js itself? More use cases!

Open up some issues on this stuff!

AsyncWrap

36:45 - Trevor

Trevor provides Async Wrap overview. One interesting detail on Async Wrap is that it deals with async activities categorized into "providers". Sounds like there may be affinity between these "providers" and v8 tracing categories.

APMs are interested in this? Originated from Continuation Local Storage work done by APMs, AsyncWrap is a more centralized version of that.

Seems like a good place for v8 tracing events to be emitted. Good use case for how trace event emitters can be added to Node.js.

Can this be used for long-stack traces? Not today, as timers don't fit in here. Trevor is thinking about how might work. Also, Node.js can't tie into micro-task queue/scheduler. Need an API from v8 to query into this. Could monkey-patch Promise/etc in user-land, but ... messy. (But is also something APMs do). Need API to callback just before micro-task callback is invoked, and after, users will need to collect/stitch together context in these calls.

Ben and Trevor will come up with proposed API to submit to V8.

AsyncWrap itself is missing a few places to allow context to be collected/stitched together, Andreas has details, will create some test cases in issues against AsyncWrap.

status of the docs - break into smaller steps

53:47 - Patrick

No actual updates, but folds into creating issues!

wrap-up

54:45

  • action items? Not right now, creating issues!
  • next meeting? In a month? No nays, so, schedule a meeting in Nov.
    • every two weeks if action items to discuss
    • issue/doodle for next meeting in a new issue

After meeting

issues created

issues closed

Thanks to @Qard for closing these old issues: