Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracing WG Meeting 2015-09-25 #21

Closed
pmuellr opened this issue Sep 19, 2015 · 29 comments
Closed

Tracing WG Meeting 2015-09-25 #21

pmuellr opened this issue Sep 19, 2015 · 29 comments

Comments

@pmuellr
Copy link
Contributor

pmuellr commented Sep 19, 2015

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)

@matthewloring
Copy link

@pmuellr I would like to join in on this meeting

@AndreasMadsen
Copy link
Member

I'm not sure I will be able to make it, so I will just take an observer seat.

@lucamaraschi
Copy link

IN!

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 20, 2015

@matthewloring, @AndreasMadsen - send an email for the google doc / hangout, to pmuellr@gmail.com

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 21, 2015

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.

@AndreasMadsen
Copy link
Member

This is the list of async_wrap issues that I could remember:

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.

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 23, 2015

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.

@trevnorris
Copy link

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 via process.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 the AsyncWrap class.

  • 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 TimerWrap instance 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 *Wrap have a unique id, which could allow filtering of these calls.

Also note there are cases like net.createServer() that will not trigger AsyncWrap until .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 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.

@Qard
Copy link
Member

Qard commented Sep 23, 2015

Did you invite @bnoordhuis? He expressed interest in attending over in #19.

@Qard
Copy link
Member

Qard commented Sep 23, 2015

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.

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 23, 2015

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.

@ofrobots
Copy link
Contributor

I was trying to get @fmeawad to join the meeting. He's the chrome dev working on getting trace-event into V8, but I don't think he can make this particular time-slot.

@yury-s
Copy link

yury-s commented Sep 24, 2015

@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.

@Qard
Copy link
Member

Qard commented Sep 24, 2015

@yury-s Yep, I'm not suggesting it is a blocker. I just felt like many here would be interested in the work you are doing and might be able to lend a hand. 😄

@fmeawad
Copy link

fmeawad commented Sep 24, 2015

Adding @natduca @paulirish @chiniforooshan

@bnoordhuis
Copy link
Member

Got the invite now (thanks @pmuellr) but I may have a conflicting schedule. Will try to join Friday but don't wait for me.

@AndreasMadsen
Copy link
Member

I'm quite sure I will be able to make it. So see you on Friday.

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 25, 2015

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.

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 25, 2015

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

@lucamaraschi
Copy link

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?

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 25, 2015

@lucamaraschi yes, the Hangout should be recorded, if I don't screw up :-)

@thlorenz
Copy link

@ofrobots @natduca until the next meeting could you please link any code/specs implementations or examples that would allow us to get a better understanding of what we'd have to implement in order to use the tracing facilities you described?

I'd greatly appreciate it.

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 28, 2015

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.

@pmuellr
Copy link
Contributor Author

pmuellr commented Sep 28, 2015

I've created an issue to track the "add docs to repo" idea - #22

@ofrobots
Copy link
Contributor

@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
Copy link
Contributor Author

pmuellr commented Sep 28, 2015

I've got the meeting minutes in a PR - #23

Someone want to merge it? And give me commit access? :-)

@Qard
Copy link
Member

Qard commented Sep 28, 2015

@pmuellr Request to join https://github.com/orgs/nodejs/teams/tracing and you should get in.

@thlorenz
Copy link

Thanks @ofrobots will find some time to digest this all.

@Qard Qard mentioned this issue Oct 7, 2015
5 tasks
@Qard
Copy link
Member

Qard commented Oct 7, 2015

I'm closing this, as the meeting has passed and the important comments have been copied or linked to in other issues now.

@Qard Qard closed this as completed Oct 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests