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

Report async tasks to V8 Inspector #13870

Closed
wants to merge 5 commits into
base: master
from

Conversation

@bajtos
Contributor

bajtos commented Jun 22, 2017

Implement a special async-hook listener that forwards information about async tasks to V8Inspector asyncTask* API.

Fixes: #11370

screen shot 2017-06-22 at 11 14 09

Note: this is an initial (incomplete) version to gather feedback early.

Here are few important items that I would like to discuss besides whatever other feedback you can provide:

  • Test coverage. Ideally, we should cover most/all major scenarios, not only setTimeout and Promises. OTOH, I'd rather avoid duplicating all async_hook/async_wrap tests, because that would add too much maintenance burden IMO. Initially, I added only two simple tests - one for promises, the second one for setTimeout. What other scenarios should I add?

  • Test assertions. Right now, the tests are only checking whether async stack information is present, the correctness of this information is not verified. Do we want the tests to verify it?

  • How to enable/disable inspector async hook when the inspector is started/stopped? I think it's important to enable this hook only when debugging in order to avoid the performance costs of async hooks. However, I was not able to find the right place where to add enable/disable call. Can anybody point me to the right direction please?

There are two test failures right now, I believe they are caused by the fact that inspector async hook is always enabled, while the tests are relying on the async hook machinery to be disabled by default.

People that may be interested in reviewing these changes, based on the git history (the list is almost certainly incomplete):
@trevnorris @addaleax @AndreasMadsen @matthewloring @eugeneo

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

async_hooks, async_wrap, inspector

Show outdated Hide outdated src/async-wrap.cc
Show outdated Hide outdated src/async-wrap.cc
Show outdated Hide outdated src/async-wrap.cc
Show outdated Hide outdated src/inspector_agent.cc
Show outdated Hide outdated lib/async_hooks.js
Show outdated Hide outdated src/async-wrap.cc
@bajtos

This comment has been minimized.

Show comment
Hide comment
@bajtos

bajtos Jun 22, 2017

Contributor

@addaleax hey, that was fast, thank you for the review! I fixed the coding style issue you have pointed, see the two new commits above.

Regarding where to keep the AsyncTask-related code: I guess it makes sense to move the C++ stuff from src/async_wrap.cc to src/inspector_agent.cc.

However, I am not so sure about moving the javascript part to lib/inspector.js. lib/inspector.js is not loaded by Node.js at startup time, therefore my async_hook is not enabled and the whole thing breaks. Also according to the docs, the inspector module provides an API for interacting with the V8 inspector. The code I am adding is not for interacting with the V8 inspector, but it's a necessary integration between Node.js/libuv and V8.

Thoughts?

Contributor

bajtos commented Jun 22, 2017

@addaleax hey, that was fast, thank you for the review! I fixed the coding style issue you have pointed, see the two new commits above.

Regarding where to keep the AsyncTask-related code: I guess it makes sense to move the C++ stuff from src/async_wrap.cc to src/inspector_agent.cc.

However, I am not so sure about moving the javascript part to lib/inspector.js. lib/inspector.js is not loaded by Node.js at startup time, therefore my async_hook is not enabled and the whole thing breaks. Also according to the docs, the inspector module provides an API for interacting with the V8 inspector. The code I am adding is not for interacting with the V8 inspector, but it's a necessary integration between Node.js/libuv and V8.

Thoughts?

@bajtos

This comment has been minimized.

Show comment
Hide comment
@bajtos

bajtos Jun 22, 2017

Contributor

Should I perhaps place the JS part into lib/internal/inspector.js?

Contributor

bajtos commented Jun 22, 2017

Should I perhaps place the JS part into lib/internal/inspector.js?

Show outdated Hide outdated src/async-wrap.cc
Show outdated Hide outdated src/async-wrap.cc
@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Jun 22, 2017

Member

Should I perhaps place the JS part into lib/internal/inspector.js?

That seems perfectly fine to me. 👍

Member

addaleax commented Jun 22, 2017

Should I perhaps place the JS part into lib/internal/inspector.js?

That seems perfectly fine to me. 👍

@eugeneo

This comment has been minimized.

Show comment
Hide comment
@eugeneo

eugeneo Jun 22, 2017

Contributor

@ak239 - please take a look.

Contributor

eugeneo commented Jun 22, 2017

@ak239 - please take a look.

@bajtos

This comment has been minimized.

Show comment
Hide comment
@bajtos

bajtos Jun 23, 2017

Contributor

Thank you all for your feedback! I cleaned up the code based on your suggestions:

  • improved assertion messages
  • added as shared C++ method for invoking AsyncTask* functions with a single taskId argument
  • moved the hook implementation to lib/internal/inspector_async_hook.js

Next step for me: enable/disable the hook from inspector agent, per @addaleax suggestion in #13870 (comment)

A possible next step for you, the reviewers: reach a consensus on what style I should use for converting arguments from JS to C++ (see #13870 (comment)), and where to check/assert the type of these arguments (see #13870 (comment)).

Contributor

bajtos commented Jun 23, 2017

Thank you all for your feedback! I cleaned up the code based on your suggestions:

  • improved assertion messages
  • added as shared C++ method for invoking AsyncTask* functions with a single taskId argument
  • moved the hook implementation to lib/internal/inspector_async_hook.js

Next step for me: enable/disable the hook from inspector agent, per @addaleax suggestion in #13870 (comment)

A possible next step for you, the reviewers: reach a consensus on what style I should use for converting arguments from JS to C++ (see #13870 (comment)), and where to check/assert the type of these arguments (see #13870 (comment)).

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Jun 23, 2017

Member

A possible next step for you, the reviewers: reach a consensus on what style I should use for converting arguments from JS to C++ (see #13870 (comment)), and where to check/assert the type of these arguments (see #13870 (comment)).

As for typechecking, I think the idea was to if (…) throw errors.TypeError(); in JS land in any case (and I’m okay with that).

After that, you can just use arg->IntegerValue(ctx).FromJust(), it’s fine by me (but for the record, if you don’t know that arg is a number that potentially does much more complex work than arg.As<Integer>()->Value()).

Member

addaleax commented Jun 23, 2017

A possible next step for you, the reviewers: reach a consensus on what style I should use for converting arguments from JS to C++ (see #13870 (comment)), and where to check/assert the type of these arguments (see #13870 (comment)).

As for typechecking, I think the idea was to if (…) throw errors.TypeError(); in JS land in any case (and I’m okay with that).

After that, you can just use arg->IntegerValue(ctx).FromJust(), it’s fine by me (but for the record, if you don’t know that arg is a number that potentially does much more complex work than arg.As<Integer>()->Value()).

Show outdated Hide outdated lib/async_hooks.js
Show outdated Hide outdated lib/internal/inspector_async_hook.js
@trevnorris

Biggest blocker I see is the usage of intptr_t on 32bit builds. Hopefully I'm overlooking something that won't make that a problem.

Show outdated Hide outdated lib/internal/inspector_async_hook.js
Show outdated Hide outdated src/inspector_agent.cc
Show outdated Hide outdated test/inspector/inspector-helper.js
@bajtos

This comment has been minimized.

Show comment
Hide comment
@bajtos

bajtos Jun 30, 2017

Contributor

Thanks @trevnorris for joining the discussion! I'm leaving for vacation later today, I'll review and respond to your comments when I get back, after July 10th.

Contributor

bajtos commented Jun 30, 2017

Thanks @trevnorris for joining the discussion! I'm leaving for vacation later today, I'll review and respond to your comments when I get back, after July 10th.

@bajtos

This comment has been minimized.

Show comment
Hide comment
@bajtos

bajtos Jul 11, 2017

Contributor

Hello 👋

I have reworked the initialisation of inspector async hook:

  1. Introduced a new property process._inspected that we use to detect whether the process was started with --inspect or --inspect-brk. I could expose this property on inspector binding instead, but it occurred to me that this flag may be useful outside of Node.js core too - see e.g. petkaantonov/bluebird#1364 Having said that, I don't really mind to move the property somewhere else if you prefer. See 1f374ab

  2. Reworked the initialisation in bootstrap_node, I also had to fix C++ side to use Persistent instead of Local handle, see eab9884. TBH, I don't understand this nuance very much, Environment seems to be using a different technique to store persistent JS callbacks. I am also not sure whether this code supports multiple isolates correctly. @bnoordhuis would you mind taking a look?

  3. The remaining commits are addressing your review comments.

Could you PTAL at my changes again please?

Contributor

bajtos commented Jul 11, 2017

Hello 👋

I have reworked the initialisation of inspector async hook:

  1. Introduced a new property process._inspected that we use to detect whether the process was started with --inspect or --inspect-brk. I could expose this property on inspector binding instead, but it occurred to me that this flag may be useful outside of Node.js core too - see e.g. petkaantonov/bluebird#1364 Having said that, I don't really mind to move the property somewhere else if you prefer. See 1f374ab

  2. Reworked the initialisation in bootstrap_node, I also had to fix C++ side to use Persistent instead of Local handle, see eab9884. TBH, I don't understand this nuance very much, Environment seems to be using a different technique to store persistent JS callbacks. I am also not sure whether this code supports multiple isolates correctly. @bnoordhuis would you mind taking a look?

  3. The remaining commits are addressing your review comments.

Could you PTAL at my changes again please?

@trevnorris

This comment has been minimized.

Show comment
Hide comment
@trevnorris

trevnorris Jul 12, 2017

Contributor

Introduced a new property process._inspected that we use to detect whether the process was started with --inspect or --inspect-brk.

Not to be done in this PR, but just a note for the future. We should really create an object or similar that has these. e.g.

if (process.flags['--inspect']) { }

// Or a call that automatically does `-_` replacement
process.hasExecFlag = function hasExecFlag(flag) {
  if (typeof flag !== 'string') throw new TypeError('must be a string');
  flag = flag.replace('_', '-');
  for (const str of process.execArgv)
    if (str === flag) return true;
  return false;
};

I could expose this property on inspector binding instead, but it occurred to me that this flag may be useful outside of Node.js core

Exposing it on inspector might be better for the moment to see if something like the above should land instead. That way we don't have to back peddle a property. If we want to then a PR that does this can be whipped up quickly.

Contributor

trevnorris commented Jul 12, 2017

Introduced a new property process._inspected that we use to detect whether the process was started with --inspect or --inspect-brk.

Not to be done in this PR, but just a note for the future. We should really create an object or similar that has these. e.g.

if (process.flags['--inspect']) { }

// Or a call that automatically does `-_` replacement
process.hasExecFlag = function hasExecFlag(flag) {
  if (typeof flag !== 'string') throw new TypeError('must be a string');
  flag = flag.replace('_', '-');
  for (const str of process.execArgv)
    if (str === flag) return true;
  return false;
};

I could expose this property on inspector binding instead, but it occurred to me that this flag may be useful outside of Node.js core

Exposing it on inspector might be better for the moment to see if something like the above should land instead. That way we don't have to back peddle a property. If we want to then a PR that does this can be whipped up quickly.

Show outdated Hide outdated src/inspector_agent.cc
Show outdated Hide outdated src/inspector_agent.cc
Show outdated Hide outdated src/inspector_agent.cc
},
destroy(asyncId) {
inspector.asyncTaskCanceled(asyncId);

This comment has been minimized.

@trevnorris

trevnorris Jul 12, 2017

Contributor

does "canceled" mean that no other "started"/"finished" calls can be made? b/c when I read that it sounds like the async task was supposed to fire a "started", but was destroyed before that happened.

@trevnorris

trevnorris Jul 12, 2017

Contributor

does "canceled" mean that no other "started"/"finished" calls can be made? b/c when I read that it sounds like the async task was supposed to fire a "started", but was destroyed before that happened.

This comment has been minimized.

@bajtos

bajtos Jul 13, 2017

Contributor

Good point, it looks a bit suspicious to me as well. @ak239 could you perhaps help us to understand this better?

@bajtos

bajtos Jul 13, 2017

Contributor

Good point, it looks a bit suspicious to me as well. @ak239 could you perhaps help us to understand this better?

This comment has been minimized.

@ak239

ak239 Jul 13, 2017

Member

Your understanding is right. asyncTaskCanceled means that asynchronous task would never be executed again (no other started/finished calls) so on inspector side we can cleanup all related to this task data.

@ak239

ak239 Jul 13, 2017

Member

Your understanding is right. asyncTaskCanceled means that asynchronous task would never be executed again (no other started/finished calls) so on inspector side we can cleanup all related to this task data.

Show outdated Hide outdated lib/internal/inspector_async_hook.js
// Even with --inspect, the default async call stack depth is 0. We need a
// chance to call Debugger.setAsyncCallStackDepth *before* activating the timer
// for async stack traces to work.

This comment has been minimized.

@bajtos

bajtos Aug 17, 2017

Contributor

Wow, good catch, it didn't occur to me that async call stacks depths may be zero and therefore there will be no async stack recorded.

@bajtos

bajtos Aug 17, 2017

Contributor

Wow, good catch, it didn't occur to me that async call stacks depths may be zero and therefore there will be no async stack recorded.

This comment has been minimized.

@TimothyGu

TimothyGu Aug 17, 2017

Member

Here's the offending code if you're interested:

V8Debugger::V8Debugger(v8::Isolate* isolate, V8InspectorImpl* inspector)
: m_isolate(isolate),
m_inspector(inspector),
m_enableCount(0),
m_breakpointsActivated(true),
m_ignoreScriptParsedEventsCounter(0),
m_maxAsyncCallStacks(kMaxAsyncTaskStacks),
m_maxAsyncCallStackDepth(0),
m_pauseOnExceptionsState(v8::debug::NoBreakOnException),
m_wasmTranslation(isolate) {}

@TimothyGu

TimothyGu Aug 17, 2017

Member

Here's the offending code if you're interested:

V8Debugger::V8Debugger(v8::Isolate* isolate, V8InspectorImpl* inspector)
: m_isolate(isolate),
m_inspector(inspector),
m_enableCount(0),
m_breakpointsActivated(true),
m_ignoreScriptParsedEventsCounter(0),
m_maxAsyncCallStacks(kMaxAsyncTaskStacks),
m_maxAsyncCallStackDepth(0),
m_pauseOnExceptionsState(v8::debug::NoBreakOnException),
m_wasmTranslation(isolate) {}

This comment has been minimized.

@bajtos

bajtos Aug 17, 2017

Contributor

IIUC, this actually means that even though we enable inspector async hook reporting AsyncTask events to V8 Inspector at startup, the async stack traces are effectively disabled until the debugger connects and increases m_maxAsyncCallStackDepth.

I think this make the user experience little bit less worse, because async workflows started before the debugger has connected will not be captured by V8 Inspector.

It makes me wonder if there is a way how to increase m_maxAsyncCallStackDepth at the time when the async hook reporting AsyncTasks is enabled? That way the two problematic tests setup-at-inspect and setup-at-signal can be simplified back to the original form.

Anyways, I think this it will be better to land this pull request as it is, because even if we don't capture async stack traces from the time before the debugger client was connected, it's still better to have some async stack traces with the current code in this patch, rather than have no async stack traces as is the current status in master.

@bajtos

bajtos Aug 17, 2017

Contributor

IIUC, this actually means that even though we enable inspector async hook reporting AsyncTask events to V8 Inspector at startup, the async stack traces are effectively disabled until the debugger connects and increases m_maxAsyncCallStackDepth.

I think this make the user experience little bit less worse, because async workflows started before the debugger has connected will not be captured by V8 Inspector.

It makes me wonder if there is a way how to increase m_maxAsyncCallStackDepth at the time when the async hook reporting AsyncTasks is enabled? That way the two problematic tests setup-at-inspect and setup-at-signal can be simplified back to the original form.

Anyways, I think this it will be better to land this pull request as it is, because even if we don't capture async stack traces from the time before the debugger client was connected, it's still better to have some async stack traces with the current code in this patch, rather than have no async stack traces as is the current status in master.

'params': { 'maxDepth': 10 } },
{ 'method': 'Debugger.setBlackboxPatterns',
'params': { 'patterns': [] } },
{ 'method': 'Runtime.runIfWaitingForDebugger' }

This comment has been minimized.

@bajtos

bajtos Aug 17, 2017

Contributor

This block of commands is duplicated in several tests. In my original code, I had a shared helper function to keep them in one place (DRY).

@bajtos

bajtos Aug 17, 2017

Contributor

This block of commands is duplicated in several tests. In my original code, I had a shared helper function to keep them in one place (DRY).

This comment has been minimized.

@TimothyGu

TimothyGu Aug 17, 2017

Member

Indeed, but the varying nature of the various tests under inspector/ mean that these commands aren't really applicable to many tests other than the async stack trace ones.

@TimothyGu

TimothyGu Aug 17, 2017

Member

Indeed, but the varying nature of the various tests under inspector/ mean that these commands aren't really applicable to many tests other than the async stack trace ones.

This comment has been minimized.

@bajtos

bajtos Aug 17, 2017

Contributor

Sure, these commands not applicable to all tests, but since there are already at least three tests using them, I think it's worth extracting the helper.

Anyways, this is not a big deal, we can improve this later (if at all).

@bajtos

bajtos Aug 17, 2017

Contributor

Sure, these commands not applicable to all tests, but since there are already at least three tests using them, I think it's worth extracting the helper.

Anyways, this is not a big deal, we can improve this later (if at all).

@bajtos

This comment has been minimized.

Show comment
Hide comment
@bajtos

bajtos Aug 17, 2017

Contributor

@TimothyGu this is awesome, thank you for your help! The new code looks pretty good to me, I appreciate you have preserved my authorship in commit history :)

I think the first commit process: add "process.bits" property either needs to be reworded (the "bits" property is exposed via internal config now), or simply squashed with the main commit, because we are no longer changing public process API.

My only concern is about duplication of debugger setup commands in the test files (see #13870 (review)), but that can be addressed later, outside of scope of this pull request.

So, as far as I am concerned, the code changes are good to be landed.

However, I see few CI failures (Windows, arm) in your last CI run (https://ci.nodejs.org/job/node-test-pull-request/9701/). Have they been addressed by the commits added after your comment?

Contributor

bajtos commented Aug 17, 2017

@TimothyGu this is awesome, thank you for your help! The new code looks pretty good to me, I appreciate you have preserved my authorship in commit history :)

I think the first commit process: add "process.bits" property either needs to be reworded (the "bits" property is exposed via internal config now), or simply squashed with the main commit, because we are no longer changing public process API.

My only concern is about duplication of debugger setup commands in the test files (see #13870 (review)), but that can be addressed later, outside of scope of this pull request.

So, as far as I am concerned, the code changes are good to be landed.

However, I see few CI failures (Windows, arm) in your last CI run (https://ci.nodejs.org/job/node-test-pull-request/9701/). Have they been addressed by the commits added after your comment?

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 17, 2017

Member

@bajtos The CI failures seem unrelated to this PR. The ARM one's linker is iffy. The Windows one was weird, but since it's just one configuration (and the failure isn't in any of the new tests) I wouldn't worry too much about it if it can't be reproduced. Rerun: https://ci.nodejs.org/job/node-test-commit-windows-fanned/11143/

Member

TimothyGu commented Aug 17, 2017

@bajtos The CI failures seem unrelated to this PR. The ARM one's linker is iffy. The Windows one was weird, but since it's just one configuration (and the failure isn't in any of the new tests) I wouldn't worry too much about it if it can't be reproduced. Rerun: https://ci.nodejs.org/job/node-test-commit-windows-fanned/11143/

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 17, 2017

Member

Rerun is green. Landed in be63c26...a0895ed 🎊

Member

TimothyGu commented Aug 17, 2017

Rerun is green. Landed in be63c26...a0895ed 🎊

@TimothyGu TimothyGu closed this Aug 17, 2017

TimothyGu added a commit that referenced this pull request Aug 17, 2017

test: fix inspector helper port sniffing
PR-URL: #13870
Reviewed-By: Miroslav Bajtoš <mbajtoss@gmail.com>

TimothyGu added a commit that referenced this pull request Aug 17, 2017

inspector: enable async stack traces
Implement a special async_hooks listener that forwards information
about async tasks to V8Inspector asyncTask* API, thus enabling
DevTools feature "async stack traces".

The feature is enabled only on 64bit platforms due to a technical
limitation of V8 Inspector: inspector uses a pointer as a task id,
while async_hooks use 64bit numbers as ids.

To avoid performance penalty of async_hooks when not debugging,
the new listener is enabled only when the process enters a debug mode:

 - When the process is started with `--inspect` or `--inspect-brk`,
   the listener is enabled immediately and async stack traces
   lead all the way to the first tick of the event loop.

 - When the debug mode is enabled via SIGUSR1 or `_debugProcess()`,
   the listener is enabled together with the debugger. As a result,
   only async operations started after the signal was received
   will be correctly observed and reported to V8 Inspector. For example,
   a `setInterval()` called in the first tick of the event will not be
   shown in the async stack trace when the callback is invoked. This
   behaviour is consistent with Chrome DevTools.

Last but not least, this commit fixes handling of InspectorAgent's
internal property `enabled_` to ensure it's set back to `false`
after the debugger is deactivated (typically via `process._debugEnd()`).

Fixes: #11370
PR-URL: #13870
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Anna Henningsen <anna@addaleax.net>
@bajtos

This comment has been minimized.

Show comment
Hide comment
@bajtos

bajtos Aug 17, 2017

Contributor

Awesome! I'd like to thank everybody who was involved in this long-lived pull request and helped me to make this happen. I really appreciated your help!

Contributor

bajtos commented Aug 17, 2017

Awesome! I'd like to thank everybody who was involved in this long-lived pull request and helped me to make this happen. I really appreciated your help!

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Aug 22, 2017

Member

Belated LGTM, sorry @bajtos, I was vacationing when you asked me to relook.

Member

sam-github commented Aug 22, 2017

Belated LGTM, sorry @bajtos, I was vacationing when you asked me to relook.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Aug 22, 2017

Member

Should this get a notable change label?

Member

Trott commented Aug 22, 2017

Should this get a notable change label?

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Aug 22, 2017

Member

@Trott yes! added it :)

Member

addaleax commented Aug 22, 2017

@Trott yes! added it :)

MylesBorins added a commit that referenced this pull request Sep 10, 2017

test: fix inspector helper port sniffing
PR-URL: #13870
Reviewed-By: Miroslav Bajtoš <mbajtoss@gmail.com>

MylesBorins added a commit that referenced this pull request Sep 10, 2017

inspector: enable async stack traces
Implement a special async_hooks listener that forwards information
about async tasks to V8Inspector asyncTask* API, thus enabling
DevTools feature "async stack traces".

The feature is enabled only on 64bit platforms due to a technical
limitation of V8 Inspector: inspector uses a pointer as a task id,
while async_hooks use 64bit numbers as ids.

To avoid performance penalty of async_hooks when not debugging,
the new listener is enabled only when the process enters a debug mode:

 - When the process is started with `--inspect` or `--inspect-brk`,
   the listener is enabled immediately and async stack traces
   lead all the way to the first tick of the event loop.

 - When the debug mode is enabled via SIGUSR1 or `_debugProcess()`,
   the listener is enabled together with the debugger. As a result,
   only async operations started after the signal was received
   will be correctly observed and reported to V8 Inspector. For example,
   a `setInterval()` called in the first tick of the event will not be
   shown in the async stack trace when the callback is invoked. This
   behaviour is consistent with Chrome DevTools.

Last but not least, this commit fixes handling of InspectorAgent's
internal property `enabled_` to ensure it's set back to `false`
after the debugger is deactivated (typically via `process._debugEnd()`).

Fixes: #11370
PR-URL: #13870
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Anna Henningsen <anna@addaleax.net>

@MylesBorins MylesBorins referenced this pull request Sep 10, 2017

Merged

v8.5.0 proposal #15308

MylesBorins added a commit that referenced this pull request Sep 11, 2017

test: fix inspector helper port sniffing
PR-URL: #13870
Reviewed-By: Miroslav Bajtoš <mbajtoss@gmail.com>

MylesBorins added a commit that referenced this pull request Sep 11, 2017

inspector: enable async stack traces
Implement a special async_hooks listener that forwards information
about async tasks to V8Inspector asyncTask* API, thus enabling
DevTools feature "async stack traces".

The feature is enabled only on 64bit platforms due to a technical
limitation of V8 Inspector: inspector uses a pointer as a task id,
while async_hooks use 64bit numbers as ids.

To avoid performance penalty of async_hooks when not debugging,
the new listener is enabled only when the process enters a debug mode:

 - When the process is started with `--inspect` or `--inspect-brk`,
   the listener is enabled immediately and async stack traces
   lead all the way to the first tick of the event loop.

 - When the debug mode is enabled via SIGUSR1 or `_debugProcess()`,
   the listener is enabled together with the debugger. As a result,
   only async operations started after the signal was received
   will be correctly observed and reported to V8 Inspector. For example,
   a `setInterval()` called in the first tick of the event will not be
   shown in the async stack trace when the callback is invoked. This
   behaviour is consistent with Chrome DevTools.

Last but not least, this commit fixes handling of InspectorAgent's
internal property `enabled_` to ensure it's set back to `false`
after the debugger is deactivated (typically via `process._debugEnd()`).

Fixes: #11370
PR-URL: #13870
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Anna Henningsen <anna@addaleax.net>

MylesBorins added a commit that referenced this pull request Sep 12, 2017

test: fix inspector helper port sniffing
PR-URL: #13870
Reviewed-By: Miroslav Bajtoš <mbajtoss@gmail.com>

MylesBorins added a commit that referenced this pull request Sep 12, 2017

inspector: enable async stack traces
Implement a special async_hooks listener that forwards information
about async tasks to V8Inspector asyncTask* API, thus enabling
DevTools feature "async stack traces".

The feature is enabled only on 64bit platforms due to a technical
limitation of V8 Inspector: inspector uses a pointer as a task id,
while async_hooks use 64bit numbers as ids.

To avoid performance penalty of async_hooks when not debugging,
the new listener is enabled only when the process enters a debug mode:

 - When the process is started with `--inspect` or `--inspect-brk`,
   the listener is enabled immediately and async stack traces
   lead all the way to the first tick of the event loop.

 - When the debug mode is enabled via SIGUSR1 or `_debugProcess()`,
   the listener is enabled together with the debugger. As a result,
   only async operations started after the signal was received
   will be correctly observed and reported to V8 Inspector. For example,
   a `setInterval()` called in the first tick of the event will not be
   shown in the async stack trace when the callback is invoked. This
   behaviour is consistent with Chrome DevTools.

Last but not least, this commit fixes handling of InspectorAgent's
internal property `enabled_` to ensure it's set back to `false`
after the debugger is deactivated (typically via `process._debugEnd()`).

Fixes: #11370
PR-URL: #13870
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Anna Henningsen <anna@addaleax.net>

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

addaleax added a commit to addaleax/node that referenced this pull request Sep 13, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  nodejs#14875

* console:
  * Implement minimal `console.group()`.
  nodejs#14910

* deps:
  * upgrade libuv to 1.14.1
    nodejs#14866
  * update nghttp2 to v1.25.0
    nodejs#14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    nodejs#14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    nodejs#15034

* inspector:
  * Enable async stack traces
    nodejs#13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    nodejs#14369

* napi:
  * implement promise
    nodejs#14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    nodejs#14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    nodejs#14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](nodejs#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: nodejs#15308

@paulirish paulirish referenced this pull request Oct 9, 2017

Closed

Promise long stack traces #979

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 12, 2018

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  nodejs#14875

* console:
  * Implement minimal `console.group()`.
  nodejs#14910

* deps:
  * upgrade libuv to 1.14.1
    nodejs#14866
  * update nghttp2 to v1.25.0
    nodejs#14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    nodejs#14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    nodejs#15034

* inspector:
  * Enable async stack traces
    nodejs#13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    nodejs#14369

* napi:
  * implement promise
    nodejs#14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    nodejs#14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    nodejs#14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](nodejs#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

This applies parts of a10856a that are
relevant to N-API.

PR-URL: nodejs#15308

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 15, 2018

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  nodejs#14875

* console:
  * Implement minimal `console.group()`.
  nodejs#14910

* deps:
  * upgrade libuv to 1.14.1
    nodejs#14866
  * update nghttp2 to v1.25.0
    nodejs#14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    nodejs#14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    nodejs#15034

* inspector:
  * Enable async stack traces
    nodejs#13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    nodejs#14369

* napi:
  * implement promise
    nodejs#14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    nodejs#14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    nodejs#14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](nodejs#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

This applies parts of a10856a that are
relevant to N-API.

PR-URL: nodejs#15308
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment