Repository navigation
Tracing WG Meeting 2015-09-25 #21
Description
Activity
@pmuellr I would like to join in on this meeting
I'm not sure I will be able to make it, so I will just take an observer seat.
IN!
@matthewloring, @AndreasMadsen - send an email for the google doc / hangout, to pmuellr@gmail.com
I've added a number of folks for editing on the agenda doc, and on the newly created Hangouts On Air event. Let me know if you didn't see notice of this, and if the various links in the description don't work for you.
This is the list of async_wrap issues that I could remember:
- There are some cases where it is not possible to know the context that created the handle: AsyncWrap: TCPWrap created before MakeCallback node#2986
- It requires monkey patching to catch errors without changing the throw origin:
async-wrap: no way to catch errors without changing the throw origin node#669 - nextTick requires money patching: async-wrap: nextTick and setImmediate is ignored node#666 (closed, but still relevant)
- setTimeout, setImmediate, setInterval: shares the handle which results in an unexpected context: async-wrap: nextTick and setImmediate is ignored node#666 (closed, but still relevant)
- A handle ondestructed event would be nice. E.g.
- clearTimeout(setInterval()) never notify asyncWrap. Will particularly be an issue when setTimeout "is fixed".
- I belive net.connect() has a similar issue, the before and after event is fired multiply times, but you don’t known when the handle is no longer in use (connection closed).
- (I need to revalidate these, but I'm quite sure they still hold)
- Deprecating process.binding will be an issue for AsyncWrap: node: deprecate public access to
process.bindingnode#2768
I don't know how specific the meeting should be and some of these have already been discussed. So I will let someone wiser decide.
Guessing that @trevnorris has a fairly definitive list of async_wrap issues, but he unfortunately won't be able to make the call.
I don't know how specific the meeting should be and some of these have already been discussed. So I will let someone wiser decide.
I'm not wiser, but have some comments. :-)
At this point it looks like the "tracing" story has a few different angles - async_wrap, v8-tracing.h, platform specific tracing w/ETW/etc.
Seems like v8-tracing.h / platform-specific tracing are kinda at the same level, and async_wrap is kinda different. I guess I see it as async_wrap will be a great place to put v8-tracing.h / platform-specific trace points. Does that seem right?
If so, it would be good to come up with different "names" for these things, so we can keep straight what we're talking about, for folks coming to this as n00bs, like me.
In any case, w/r/t async_wrap, using it as an exemplar of using v8/platform tracing seems ideal. We clearly want tracing hooks there. So let's talk about it some.
Would also like to get an update on v8-tracing, from @ofrobots . @billti also provided some info on work to add ETW support for tracing to node, in #10, ICYMI.
Want to make sure everyone's on the same page about
AsyncWrap. It is a class where I centralized the creation of all class constructors that have the possibility of performing I/O. The current API exposed viaprocess.binding('async_wrap')was only created as a way to utilize the new class structure. That API could be removed easily without affecting the functionality of theAsyncWrapclass.- It requires monkey patching to catch errors without changing the throw origin
All error handling abilities were removed in the PR because of conflicts with the domain module and
uncaughtException. Took me about a month to get it right, but was then considered to big of an alteration to merge at the time.- nextTick requires money patching
- setTimeout, setImmediate, setInterval: shares the handle which results in an unexpected context
My original PR addressed these cases, but unfortunately they conflicted with domains and were eventually removed because I wanted to get the native code changes merged. This can be done, but requires making calls similar to how domains work today.
- A handle ondestructed event would be nice
This callback could not guarantee being called while the object was being destructed. Which means you would no longer have access to the object. I've toyed with an implementation in the past, but never reached a point of being useful.
- clearTimeout(setInterval()) never notify asyncWrap. Will particularly be an issue when setTimeout "is fixed".
This is because for performance there is a single
TimerWrapinstance with a JS linked list object attached that contains all the timers that will be fired in the future. So when a timer is cleared it's simply removed from the linked list.- I belive net.connect() has a similar issue, the before and after event is fired multiply times
Probably because they are also creating a
ShutdownWrap(src/stream_wrap.h). All*Wraphave a unique id, which could allow filtering of these calls.Also note there are cases like
net.createServer()that will not triggerAsyncWrapuntil.listen()is called. This is because we don't know whether the user wants a Pipe or TCP until that time. It was a serious pain to work around when I was writing the initial error handling implementation.I haven't done much with
AsyncWrapfor 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.Did you invite @bnoordhuis? He expressed interest in attending over in #19.
It'd be good to get @yury-s in there too, so we can discuss what needs to happen to keep nodejs/node#2546 moving forward.
I did not. I need to figure out how to maintain an email list from GH ids. And presumably Ben has a brand-new shiny IBM email id :-) Will send now. Both have email addresses in their GH profiles, so will send them a note.
@Qard I don't think tracing integration should be blocked by nodejs/node#2546. Once https://codereview.chromium.org/988893003/ lands into v8 it should be fairly easy to collect trace logs for v8 in Node and save them to a file. The file can be viewed with the trace-viewer by e.g. loading it into chrome:tracing
We use tracing instrumentation to populate Timeline panel in DevTools. All the instrumentation is provided by tracing. DevTools only implements a fairly simple tracing agent (100 loc) that allows to convert traces via the protocol. This agent may well be integrated into v8-inspector as long as tracing support is landed in v8. Timeline panel is targeted at web developers and tries to represent tracing data in a way understandable by people not familiar with the browser guts while tracing provides more sophisticated UI and exposes way more internal details. I believe trace-viewer may be more useful for Node developers. In any case as I said v8-inspector should not block the work on integration with tracing.
2 remaining items
Got the invite now (thanks @pmuellr) but I may have a conflicting schedule. Will try to join Friday but don't wait for me.
I'm quite sure I will be able to make it. So see you on Friday.
For anyone reading this, that's not in the list of attendees in the description of this issue (top of the web page), but wants to attend - or things they may be able to attend - please send me your email so I can add you to the Hangout.
I've updated the invite list on the hangout to include folks I noticed on previous calls, and mentioned in this issue; you can see the invite list here:
If you're not on that list, I either missed you, or couldn't find an email address for you. Either case, please send me an email you can use with Hangouts.
known email-challenged folks: @fmeawad @paulirish @chiniforooshan
Guys I think I cannot attend the call as I am in bed sick! I will try to
attend and watch but I cannot guarantee...is it going to be recorded?@lucamaraschi yes, the Hangout should be recorded, if I don't screw up :-)
One of the topics discussed in the meeting was setting up some spots in the repo to drop some documentation/diagrams/etc of all the various components that have been under discussion. I'll prime this with some structure this week, and then hopefully folks who understand the components can start filling in details.
@thlorenz: For the 'spec', the best starting point would be this comment from @natduca, and then following the linked documents from there.
Here are the main components, as per my understanding:
- trace-event.h and trace-event-common.h. These define the low-level C macros that provide a low-overhead mechanism to insert traces into C++ code. @fmeawad is working on getting these files committed into V8 under this change-list.
- As per the current CL, there a few methods that are getting added to v8-platform.h. An embedder needs to provide an implementation of these. Chromium provides the implementation of these in trace_log.h and trace_log.cc.
- To implement these functions, an embedder needs a buffer that gathers the traces. The buffer also is responsible to periodically & asynchronously flushing the contents to whatever 'sink' the traces need to go to. The Chrome implementation of the buffer is in trace_buffer.h and trace_buffer.cc.
- To implement the above in Node.js, I think we probably need a separate thread handling the flushing of the trace-buffer to keep it off the main thread. Checking if a particular trace is enabled needs to be extremely cheap, and putting something into the trace-buffer synchronously needs to be cheap.
Basically this trace-event buffer becomes the 'single pipe' through all trace-events gathered by different parts of the software stack.
Once the above linked CL lands, traces being gathered in V8 will show up there. Node.js can start putting its own traces into the same pipe. I would imagine we would also need an API in Node.js to be exposed to JavaScript to allow JS code to start sending the trace events.
@pmuellr Request to join https://github.com/orgs/nodejs/teams/tracing and you should get in.
I'm closing this, as the meeting has passed and the important comments have been copied or linked to in other issues now.
Time: 3pm Friday September 25th UTC (8am Pacific), or in your local timezone: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Tracing+WG&iso=20150925T15
Agenda and minutes can be collected in here and copied into this repo later:
https://docs.google.com/document/d/1c-mFv1WSAU4zB_p9B-5caCchv7dAqcx3kDGYVADUwgQ/edit?usp=sharing
Previous minutes: https://github.com/nodejs/tracing-wg/blob/master/wg-meetings/2015-02-19.md
Hangout on air for active participants: https://plus.google.com/hangouts/_/hoaevent/AP36tYd0g141Sb2-hvEYks-aiPi37ArGfEDhE8fQS-Gvhh03gEPQUQ
Hangout on air for viewers, event page: https://plus.google.com/events/ceccr8614j3pg3rsqcq6ev4fsik
YouTube movie for observers and saved recording: http://www.youtube.com/watch?v=yM6q92V1IDk
Current invited participants, this list is not exclusive if you think you should also join:
(will need emails for google docs/hangout setup - send to pmuellr@gmail.com)
Agenda discussion can happen in this thread.
(format copied from nodejs/Release#38)
(instructions for creating Hanouts On Air on the nodejs/node wiki)