Tracing use cases and interface

[lucamaraschi]

We discussed during the last WG about the usage interface for the V8 tracing API (on-demand vs. continuous streaming) but we should define some concrete use cases and define as our goal to achieve a usable interface for consuming and/or retrieving all the tracing informations.

[bnoordhuis]

I think a good first step would be to make sure that the tracing infrastructure can do what the dtrace/etw/lttng/systemtap USDT probes do now. There are only a handful of them so that shouldn't be a huge undertaking. For posterity:

lib/_http_client.js:163:  DTRACE_HTTP_CLIENT_REQUEST(this, this.connection);
lib/_http_client.js:410:  DTRACE_HTTP_CLIENT_RESPONSE(socket, req);
lib/_http_server.js:100:  DTRACE_HTTP_SERVER_RESPONSE(this.connection);
lib/_http_server.js:473:    DTRACE_HTTP_SERVER_REQUEST(req, socket);
lib/net.js:402:  DTRACE_NET_STREAM_END(this);
lib/net.js:1424:  DTRACE_NET_SERVER_CONNECTION(socket);

(The DTRACE_ prefix is for historical reasons, we should rename them.)

Once that works, we can think about adding trace points to e.g. the ArrayBuffer allocator, the various Wrap constructors/destructors, and so on.

Sounds reasonable? Who's volunteering?

[trevnorris]

I'm fine to implement that, but what would the API be? The hooks I'm thinking of would live in the native code, not in JS.

Additionally I think it's a poor JS API decision to simply call the function and say "it's a noop". Because in reality it isn't. These should be conditionally wrapped, regardless of how ugly it looks. Especially if they're going to be injected into more and more locations in the future.

[bripkens]

@lucamaraschi: […] we should define some concrete use cases […]

From nodejs/node#4496:

As a developer, I want to see when garbage collections happen and
how long they take in the production environment so that I can get a
feeling for GC pressure and the behavior of my application.

@trevnorris: The hooks I'm thinking of would live in the native code, not in JS.

Assuming that you define hooks as "an API to access trace data": It would be neat to see a JS API for that. Main reason as outlined in nodejs/node#4496:

Users of such monitoring tools, or more generally users interested in GC activity, need to compile native addons in order to access this information. It is hard to explain why users need to do this (or have a package such as build-essential installed). This gets increasingly harder in Java shops which are used to having everything in the platform. Building these addons automatically on install only reduces this problem, but doesn't remove it.

Being able to retrieve this information from JS directly would mean that monitoring tools could ship with fewer addons.

[trevnorris]

I didn't mean there wouldn't be a JS API, only that the hooks/counters would exist in the native side.

[joshgav]

closing old AsyncWrap issues, please start a new thread if appropriate

The API and format discussion is continuing in #53