Skip to content

Latest commit

 

History

History
93 lines (73 loc) · 5.35 KB

2020-04-22.md

File metadata and controls

93 lines (73 loc) · 5.35 KB

Node.js Diagnostics WorkGroup Meeting 2020-04-22

Links

Present

  • Diagnostics team: @nodejs/diagnostics
  • Stephen Belanger @qard
  • Michael Dawson (@mhdawson)
  • Gireesh Punathil (@gireeshpunathil)
  • Chengzhong Wu (@legendecas)
  • Peter Marton (@hekike)
  • Harshitha K P (@harshithakp)
  • Matheus Marchini (@mmarchini)

Agenda

Announcements

*Extracted from diag-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/diagnostics

  • Deep dives are pushed out currently because of many topics

    • Gireesh: earlier we switched two bi-weekly because of low attendance
    • Michael: we could add to calendar
    • Peter: should we try this approach and create a deep dive next week and normal meeting after that
    • Mattheus: we could always just skip meetings if there is not enough topic
    • Stephen: I’d rather meet more frequently than running out of time
    • Michael: I’ll add to the calendar

  • self nomination to diagnostics working group #379

    • Peter: Many approves, what’s the action item here
    • Michael: our rules say we to add to agenda for visibility

  • Harshitha: working with Gireesh and interested in Diagnostics

    • Looking into collaborating more into diagnostics and improving tooling
    • Currently interested in Node Report and Heap Profiling

  • COVID-19 and WG sittings #370

    • No concerns/comments this week

  • proposal: elevate diagnostic report to tier1 #369

    • Gireesh: Process was approved, raised in main repo now
    • After waiting for seven days we could process, but we have only one approval at the moment
    • Michael: did I approve?
    • Gireesh: One comment about putting back the old report to unclassified
    • Michael: sounds good I’ll take a look
    • PR, please take look: nodejs/node#32732

  • reportVersion semantics are not defined #349

    • Mattheus will map schema changes versioning

  • Proposal to drive Diagnostics WG initiatives through user journeys #295

    • Next week April 29 we will do a deep dive (CPU Profiling)

  • Node CPU Profiling Roadmap #148

  • Matheus: discussion restarted on the issue about what’s the proper way to do CPU profiling on Node.js

  • Today it’s not clear to users which tools are available and supported

  • Some concerns around V8 Profiler performance that was raised 2-3 years ago, but it wasn’t tackled

  • CPU Profiling always happen on V8, so if we want to improve and make more production safe, we need to engage with V8 team

  • I think we need to figure out how to engage with V8 and collaborate on this

  • Michael: In theory we could contribute to V8

  • Peter: I think next week deep dive will be good starting point for what’s available and gaps

  • Michael: we could layout what’s need to be improved with gaps and discuss with them who can work on it

  • Gireesh: user journeys could help to identify these gaps and action items

  • If you ping V8 team they reply, but they seems less proactively

  • Matheus: we should align with V8 before we open PRs

  • Matheus: we could also reach out to Chrome Dev Tools team as APIs they have to use are the same we need and maybe they have more resources to work on

  • Process plan: collect user journeys on next meeting -> add old items -> write down gaps and requests -> reach out to V8 and Chrome Dev tools -> invite them to our meeting

  • [async_hooks] stable API - tracking issue #124

    • napi_make_callback issue: nodejs/node#32930
    • fast-path promise hook: nodejs/node#32891
    • reviving zones proposal: #375
    • Stephen: napi_make_callback has an issue, there is a PR but not sure if it’s safe. I could use some eyes, maybe someone with more N-API expertise: it’s swapping out the async struct to a new class and I’m not sure it’s safe

  • WG: Approach makes sense, we just need to review PR

  • Stephen: fast-promise for promise hook; if there is no destroy hook it will just use JS implementation which doesn’t do GC tracking and emits destroy events. I’ve an open PR, functionality is there, need to solve an issue around the test suite and resolve PR comments. *Legendecas: zone proposal; we discussed the proposal, question around if error handling should be included in the proposal. Maybe we could present the proposal in TC39, we have to prepare the proposal text before we present (maybe on incubator call of May 12).

  • Stephen: various efforts to update domains to use zones. Would we include it in the proposal?

  • Legendecas will work on the proposal and would be interested to involve more people

  • Michael: it would be a good idea to sync with OpenJS Standard team, people are there involved with TC39

  • Legendecas: I can reach out to them

Q&A, Other

Upcoming Meetings