-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
"NodeTracing" domain introduction #20608
Conversation
src/inspector/node_protocol.pdl
Outdated
# total size. | ||
optional number value | ||
|
||
# Contains an bucket of collected trace events. When tracing is stopped collected events will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you omit mention of when events start streaming. This way we can later add a mode when events start streaming after start, not stop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to clarify: with this channel, are the events buffered in Node.js until a given point and then delivered or are they streamed continuously as they are emitted? The latter would be far more useful in the long run. If it's the former then it will be good to know :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@a1ph Did that.
@jasnell Right now events are sent out when trace buffer is flushed, same as writing the trace to the file. This is done to minimize performance impact (and also not to brake the trace to file). Some events will force flush, such as connecting/disconnecting an inspector session (multiple sessions are supported) or using JS API to tweak enabled categories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just thinking out loud... I wonder if it would make sense to support some signal to force flushing on demand.
src/inspector/node_protocol.pdl
Outdated
optional number value | ||
|
||
# Contains an bucket of collected trace events. When tracing is stopped collected events will be | ||
# send as a sequence of dataCollected events followed by tracingComplete event. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/send/sent/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done (I moved the comment up to the stop method)
src/inspector/node_protocol.pdl
Outdated
array of string includedCategories | ||
|
||
# Stop trace events collection. | ||
command end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather name the pair start/stop instead of start/end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a copy of the Chrome protocol - https://chromedevtools.github.io/devtools-protocol/tot/Tracing - I don't mind changing this for Node.js but I am not sure how far we want to diverge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@a1ph Renamed it.
src/inspector/node_protocol.pdl
Outdated
parameters | ||
# A number in range [0..1] that indicates the used size of event buffer as a fraction of its | ||
# total size. | ||
optional number percentFull |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the number is in [0..1] I'd not call it percent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently this structure is not used, I removed it altogether.
src/tracing/agent.cc
Outdated
RestartTracing(); | ||
if (categories.empty()) | ||
return; | ||
std::set<std::string> categories_set; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, why it's not an unordered_set ?
Actually Chrome tracing treats categories as sort of command list rather than a set. This allows you to use wildcards, e.g.
"-*,devtools.timeline" will disable all default categories and then enable just devtools.timeline. Not sure if you want to support that here though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An unordered_set would be fine here, I think. And yeah, treating these as a command set would be difficult, especially given the trace_events
JS API model
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@a1ph Node does not have a notion of "default categories" at this time and that command list is not implemented. I suppose, if it is decided to implement something similar, parsing will be done in the protocol agent so this implementation will still have this set.
src/inspector/tracing_agent.cc
Outdated
DispatchResponse TracingAgent::getCategories( | ||
std::unique_ptr<protocol::Array<String>>* categories) { | ||
*categories = Array<String>::create(); | ||
categories->get()->addItem("node"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a temp stub implementation? The actual list is dynamic and should be pulled from TracingController. Right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a hardcoded list that should ultimately be coming from the TracingController or some other place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently these are adhoc in core. We have macros for defining them, and once we have the js emit function, the category could be somewhat arbitrary. We'll need to make sure we have a good centralized place to define these.
There's one missing: `node.fs.sync'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jasnell added the category.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created nodejs/diagnostics#191 to track this as a follow-on feature.
src/inspector/node_string.h
Outdated
@@ -0,0 +1,79 @@ | |||
// Bridges V8 Inspector generated code with the std::string used by the Node | |||
// Comnpare to V8 counterpart - deps/v8/src/inspector/string-util.h |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/Comnpare/Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Looks very good on first read through. I'm not going to sign off yet as I need to run it and step through it a bit first. Would love to get @addaleax and @bnoordhuis to take a look also. Also /cc @nodejs/diagnostics |
Added a commit that addresses the review comments. |
src/inspector/tracing_agent.cc
Outdated
DispatchResponse TracingAgent::getCategories( | ||
std::unique_ptr<protocol::Array<String>>* categories) { | ||
*categories = Array<String>::create(); | ||
categories->get()->addItem("node"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Created nodejs/diagnostics#191 to track this as a follow-on feature.
src/tracing/node_trace_buffer.h
Outdated
@@ -51,7 +50,7 @@ class InternalTraceBuffer { | |||
|
|||
class NodeTraceBuffer : public TraceBuffer { | |||
public: | |||
NodeTraceBuffer(size_t max_chunks, NodeTraceWriter* trace_writer, | |||
NodeTraceBuffer(size_t max_chunks, Agent* agent, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
style nit: this should fit on one line now, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
CI: https://ci.nodejs.org/job/node-test-pull-request/14817/ It has genuine Windows failures, I'll work on them. |
CI is green. I would like to wait 48 hours for additional comments. |
src/inspector_agent.h
Outdated
Persistent<v8::Function> enable_async_hook_function_; | ||
Persistent<v8::Function> disable_async_hook_function_; | ||
v8::Persistent<v8::Function> enable_async_hook_function_; | ||
v8::Persistent<v8::Function> disable_async_hook_function_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change? node::Persistent
has the advantage of cleaning up automatically when it is destroyed, but I don’t see any Reset()
calls being added here…?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thanks! I did not realize this was something other then v8::Persistent, I now made it explicit by using the node namespace.
src/tracing/agent.cc
Outdated
}; | ||
|
||
const std::set<std::string> flatten( | ||
const std::unordered_map<int, std::set<std::string>> map) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Style nits: const
on a return value doesn’t change anything, so you can omit it. The parameter should probably be a const reference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@addaleax I addressed your comments. Please, take another look. |
@eugeneo Can’t really review this fully, but I’m happy as far as code style is concerned. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rubberstamp LGTM.
Considering the amount of code being added, it seems to be pretty low on the number of tests added.
@addaleax Thanks for the code style review. I rebased and straighten the history. New CI: https://ci.nodejs.org/job/node-test-pull-request/14909/ |
Looks like macOS bot ran out of disk space... @nodejs/build |
CI: https://ci.nodejs.org/job/node-test-pull-request/14933/ |
Landed as 47bdc71 |
Original commit message: Custom tag for the traceEvents array This API will be used by Node.js to provide output compatible with Chrome devtools. Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I265495f8af39bfc78d7fdbe43ac308f0920e817d Reviewed-on: https://chromium-review.googlesource.com/1044491 Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Eugene Ostroukhov <eostroukhov@chromium.org> Cr-Commit-Position: refs/heads/master@{#53041} PR-URL: #20608 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
This change adds a new inspector domain for receiving Node tracing data. 1. Node.js now can extend Inspector protocol with new domains with the API defined in the src/inspector/node_protocol.pdl. 2. Plumbing code will be generated at the build time. /json/protocol HTTP endpoint returns both V8 and Node.js inspector protocol. 3. "NodeTracing" domain was introduced. It is based on the Chrome "Tracing" domain. PR-URL: #20608 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
We target C++14: Line 324 in 23a56e0
|
Original commit message: Custom tag for the traceEvents array This API will be used by Node.js to provide output compatible with Chrome devtools. Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I265495f8af39bfc78d7fdbe43ac308f0920e817d Reviewed-on: https://chromium-review.googlesource.com/1044491 Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Eugene Ostroukhov <eostroukhov@chromium.org> Cr-Commit-Position: refs/heads/master@{nodejs#53041} PR-URL: nodejs#20608 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Original commit message: Custom tag for the traceEvents array This API will be used by Node.js to provide output compatible with Chrome devtools. Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I265495f8af39bfc78d7fdbe43ac308f0920e817d Reviewed-on: https://chromium-review.googlesource.com/1044491 Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Eugene Ostroukhov <eostroukhov@chromium.org> Cr-Commit-Position: refs/heads/master@{#53041} PR-URL: #20608 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Original commit message: Custom tag for the traceEvents array This API will be used by Node.js to provide output compatible with Chrome devtools. Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I265495f8af39bfc78d7fdbe43ac308f0920e817d Reviewed-on: https://chromium-review.googlesource.com/1044491 Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Eugene Ostroukhov <eostroukhov@chromium.org> Cr-Commit-Position: refs/heads/master@{#53041} PR-URL: #20608 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Should this be backported to |
Please don't backport yet. There are some stability issues in the tracing code that need to be worked out fully before backporting. |
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesThis pull request includes:
CC: @nodejs/trace-events @nodejs/v8-inspector @nodejs/diagnostics