Trace Events trace system in Node.js

[joshgav]

• This issue is to a) track progress on Google's implementation of a Trace Events Tracing Controller within V8 and b) determine if/how Node should use and build on that implementation.

For initial discussion see 2016-06-01 meeting notes.

The Chromium projects use a shared tracing system based on the macros defined in chromium/src/base/trace_event/common/trace_event_common.h. @ofrobots added this file to Node here.

Processing for traces emitted through these macros is implemented by each component, e.g. V8. For example, Chromium's implementation is here and V8's current "noop" implementation is here.

@ofrobots and @matthewloring are working on an implementation of a Tracing Controller (processor) within V8 (based on Chromium's?) which we could utilize in Node; we'll need to decide on that.

We'd still need to address the following and more ourselves in Node. Some of this discussion has begun in #30.

• If/how should user/core native and/or JS Node modules be able to publish traces via the Trace Events system? For example, we could surface APIs through console.trace.
  • V8/D8's global console object provides this.
• If/how should native and/or JS Node modules be able to subscribe to or collect traces received by the Trace Events system? For example, should we stream out all traces to listeners if requested? Dump a file?
  • The implementation which Google is working on saves all traces in memory to optimize performance; it would be up to Node to define and implement interfaces for accessing these traces in various ways.
• What should be the categories and common trace properties (e.g. timestamp, PID, backtrace) for use in Node?
• What should be the serialization/output format for trace files? Multiple tools may want to post-process, analyze, and/or visualize traces.
  • The Chromium projects have agreed on this format for now.
  • Chromium is considering a binary format based on ProtoBufs.

These details were discussed in #49's meeting.

---

Edits:

• 2016-06-09: Added link to meeting notes in repo.

[matthewloring]

I wanted to give a quick update on our tracing controller work. In addition to the tracing controller inside V8, we are working on a specialized controller for node that will handle buffering traces and serializing them using the JSON format linked above. Adding support for other output formats should extend easily.

We do not currently have a system for subscribing to trace events as we want to keep the tracing overhead as low as possible. I would be interested in learning more about the intended subscription use case so that we can come up with a system that works for everyone.

We are also hoping to collaborate on finding the correct JS interface to publish traces (e.g. console.trace). This decision should be largely independent of our current work on the controller and serialization.

[rnchamberlain]

A couple of suggested trace subscription use cases:

1. The IBM HealthCentre/appmetrics tool (and likely others) would be interested in subscribing to low-frequency and/or sampling trace events. The tool agent then transmits data using their own transport mechanism to a remote GUI client. Must be as non-invasive as possible, eg <1% performance hit.
2. Not exactly as a traditional per-event 'subscriber', but it is very useful if post-mortem tooling can access any always-on/flight-recorder trace buffers that are available in memory when a problem occurs. Usually from a core dump. So needs some available route to find the trace buffers.

[jasongin]

I am working on a JavaScript API for tracing, built on top of the chromium tracing framework being integrated by @matthewloring. I am preparing an enhancement proposal doc to gather feedback about the proposed APIs; look for that in early January since I'll be on vacation for the rest of this month.

Meanwhile if anyone wants to look at an early preview, I have an incomplete implementation working in my fork. It includes draft documentation of tracing JS APIs. To review my code before Matt's PR lands you can compare it against his fork. I'm not submitting this as a PR just yet because I want to get some feedback on an enhancement proposal first; there might be some design questions that should be discussed and settled there.

Performance for emitting tracing events from JavaScript is looking pretty good so far; I've done some basic optimization but not extensive tuning. On my dev system, a 5-year old desktop running Windows, the benchmark I wrote shows each single-category JS trace statement takes around 650ns with tracing enabled (writing events to a JSON file), or around 45ns with tracing disabled. Multi-category events are somewhat slower. (Yes those numbers are nano-seconds, not micro- or milli-seconds.)

I've also defined and documented APIs that enable JS code to listen to events, but that part is not fully implemented yet. It will depend on some changes to v8's tracing code in order to support event callbacks.