Expanding this WG to all Diagnostics for Node

[joshgav]

Hello all! I've talked to several of you over the past month about invigorating this working group and creating a greater Diagnostics team for Node. To be helpful, I wanted to come with a tentative plan and hammer out details with everyone.

To that end, following is a summary of the diagnostic domains which we can help Node cover and around which we can orient our work. I propose creating a wiki-like structure in this repo oriented around these domains and then using PRs to add new domains, interfaces and APIs, tools, samples and docs.

Note: "Post-mortem" topics are listed here under "Heap and Memory Analysis" for completeness; that work should continue in the nodejs/post-mortem team.

I also propose we restart our monthly meeting to discuss items from this list. In our next meeting, for example, we should probably discuss AsyncWrap issues and how to support the coming Chrome Debugging Protocol in V8.

Could you provide feedback on the proposed structure? If we have consensus I'll go ahead and work with @pmuellr to organize this repo accordingly.

---

Goals

• Node surfaces a set of comprehensive, documented, extensible diagnostic protocols, formats, and APIs for use by tooling clients and VM vendors.
• Enable many tool vendors to provide reliable diagnostic tools for Node.

Plans

• Collect, understand, and document existing diagnostic capabilities and entry-points throughout Node, V8, and other components.
• Collect and document projects and products providing diagnostics for Node with brief description of their technical architecture and sponsoring organizations.
• Identify and explore opportunities and gaps, feature requests, and conflicts in existing diagnostics capabilities.

Domains

• Tracing
• Profiling
• Heap and Memory Analysis
• Step Debugging
• Protocol and API

Tracing

• nodejs/tracing-wg
• System: dtrace, lttng, etw, systemtap
• V8: TRACE_EVENT
  • Requires implementation of v8::Platform::AddTraceEvent
• Node: AsyncWrap, Domains, Zones
• JavaScript: Domains, Zones

Profiling

• V8 CPU Profiler: v8::Isolate::GetCpuProfiler (include/v8-profiler.h)
  • Accessible globally through --prof, basic display through --prof-processor
  • node-inspector/v8-profiler
• V8 Heap Profiler: v8::Isolate::GetHeapProfiler (include/v8-profiler.h)
  • Also accessible through 'v8' module.
  • node-inspector/v8-profiler
• Intel vTune (./configure --enable-vtune-profiling)

Heap and Memory Analysis

• nodejs/post-mortem
• mdb_v8
• node-heapdump
• lldb_v8
• IBM IDDE
• Snapshot Utils

Step Debugging

• llnode
• node-inspector

Protocol and API

• Chrome Debugging Protocol
  • Stability and extensibility
• V8 Debugging Protocol

[joshgav]

/cc @pmuellr @trevnorris @ofrobots @yunong @nodejs/post-mortem @nodejs/tracing

[AndreasMadsen]

Step Debugging, Protocol and API, Domains, Zones, Heap and obviously Memory Analysis is not something I recall being discussed in this working group. It may belong here, but the work is typically done by voluntary interest. If it has never been discussed there may not be enough resources to support those areas.

Your proposal appears to be very much driven by the planning phase of classic project management. You are creating work breakdown structures, defining activities, planning communication, etc.. I have no objections to project management, but I can also see that you don't have many open source contributions on your github page (apologies if I'm mistaken). In my experience classic project management is best suited for being in the (cost, time) part of the iron triangle (the barycentric coordinate system with (cost, quality, time) as dimensions, though the terms vary), where open source is typically in the (cost, quality) part. This is not to say that part of project management don't apply, but in my (maybe limited) experience one also has to take a very different approach.

PS: it looks like something went wrong in your cc'ing.
/cc @nodejs/tracing @nodejs/post-mortem

[Jeff-Lewis]

IMHO Step Debugging, Protocol and API, Domains, Zones, Heap and Memory Analysis should be included or at least considered as an impact point. joshgav's contribution to the WG should be welcomed. As you know this WG is responsible for such additions to Node that will make it more mature and enterprise friendly.

[AndreasMadsen]

@Jeff-Lewis If all this can be done it would be amazing. I'm simply concerned that it can't, given the resources.

@joshgav are you planning to create all these detailed documents yourself?

[joshgav]

@AndreasMadsen I'd say my goal is to organize and facilitate diagnostics work for Node rather than manage it. Goals of such organization include discoverability for new contributors and users, transparency for contributors and tool makers, opportunity for those who have new ideas, and smooth communication between all groups and stakeholders. Execution will continue at its own pace, though I hope all this will build momentum and encourage more contributions.

And yes, I anticipate starting a lot of the work described myself over the coming weeks and months, but wanted to build general consensus as it begins. I have a nascent 80/20 theory for open source work - do 80% of the work then come to the community to make adjustments and finish the last 20%; accordingly, I view my proposal above as about 80% complete :)

[AndreasMadsen]

@joshgav Thanks, then I have no more major concerns. But other members should comment on this too.

I have a nascent 80/20 theory for open source work - do 80% of the work then come to the community to make adjustments and finish the last 20%

This was also my belief a some time ago. However I have found it much more productive to do the work as best as I can and then let the community comment on how it can be done better. Maybe that is what you meant.

edit: But feel free to do whatever work you are comfortable with, this is just my experience.

[pmuellr]

@joshgav thanks for doing this!

I have to admit that I have a bit more interest / history / knowledge on some of the "additional" items you listed, esp debugging, heap and cpu profiling. I was kinda hoping to either expand this WG out a bit more, or maybe start a new one on some of those topics.

I don't have a sense for if these end up making the WG a little too "wide" or not - guessing they might. But for lack of a better place to put them, I think there's no problem using this WG, for now, to house some of those bits.

Let's get another meeting scheduled! I've been hoping to come out of "swamped mode" for the last couple of weeks, but .. no luck. Next week is different - should have some time to schedule it then - but don't wait for me if you want to get it going ...

[pmuellr]

I'd say my goal is to organize and facilitate diagnostics work for Node rather than manage it.

Any attempts at organization, and starting to structure bits, is great. I just barely had time to organize the calls, much less anything else!

I've certainly been burned over the years by projects which attempt to over-organize things from the get-go, and end up stifling contribution. Almost always better to start with a small number of artifacts, split them up organically, as needed, into more specialized artifacts.

@joshgav Wanna draw up a "picture" (ascii indented list or whatever fine) of our current structure, and a proposed structure, and we'll take that as the action item for this issue?

I have a doc, with not a ton of info it, but at least a basic start, with some node debug context info, I've shared with other folk - https://github.com/pmuellr/node-debug-context - assume I want that in this repo, where would it go?

[mhdawson]

I'm + 1 on a putting together an overall picture of what we think is important. I think its a good way help people understand the areas that are being worked and/or the areas the community thinks are important but need more contributors to help out. @pmuellr can you include me in the doodle when we schedule the next meeting.

[pmuellr]

@mhdawson suggest you watch the repo, you'll see the next meeting scheduling exercise as a new issue ; I'll cc the team/group/whatever as well ...

[joshgav]

Awesome, thanks @pmuellr. How about I submit a PR with structure, current content and some new content and we hammer on that? Give me a few days, I'll try to have something early next week.

Seems like the Debug Context info belongs under "Step Debugging", by which I mean stopping execution on breakpoints and events/exceptions, reflecting on current state, and jumping around (stepping) to other states. Actually, ever since I started looking into Node diagnostics I've been wondering what the AsyncTaskEvent and PromiseEvent V8 debug events are and if they'd be useful for tools :)

I'm happy to set up our next meeting, do we have an agenda? Perhaps I'll start a thread soliciting agenda items and good times.

[pmuellr]

Sounds good.

Re: agenda - typically we talk about AsyncWrap and v8 trace API - get status on where those are - and then anything else. I typically create a Google Doc - I think - to let people add agenda items. Might want to look at some of the artifacts from previous meetings.

[joshgav]

Please see #47 for concrete implementation of expansion.

Working on meeting invite now.

[joshgav]

Hi all - Quick update. I've tarried on scheduling a meeting in order to have more time to prepare code and components to generate discussion, such as a small trace subsystem I'm now working on. Also, now that @trevnorris has opened an EP for AsyncWrap, perhaps that wouldn't be on our agenda here.

If everyone wants a meeting now I'll put one together. Otherwise, I'll continue to work on prototypes and implementations to generate discussion, and continue filling in the docs in #47. We can then arrange a meeting as these mature.

What do you think? Thanks!

[pmuellr]

Sorry for the delayed response.

Let's go ahead and get a meeting together. Still want to catch up with the chrome/v8 tracing work, which I don't think we've heard about in months. And the work you're doing. :-)