Garbage collection is triggered by the heap object tracker. The garbage
collector may spawn garbage collection tasks on the foreground thread.
This is only allowed after registering the isolate in the platform
which happens in IsolateData. This CL moves the starting of the heap
object tracker after calling IsolateData to ensure that.
PR-URL: https://github.com/nodejs/node/pull/17249
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Add a utility functions for addons to use when they need
a reference to the current event loop.
Currently, `uv_default_loop()` works if the embedder is the
single-threaded default node executable, but even without
the presence of e.g. workers that might not really an API
guarantee for when Node is embedded.
PR-URL: https://github.com/nodejs/node/pull/17109
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Report (for example) "node[1337]" as the human-readable name rather
than the more generic and less helpful "Node.js Main Context."
While not perfect yet, it should be an improvement to people that
debug multiple processes from DevTools, VS Code, etc.
PR-URL: https://github.com/nodejs/node/pull/17087
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
This removes the `process._needImmediateCallback` property
and its semantics of having a 1/0 switch that tells C++ whether
immediates are currently scheduled.
Instead, a counter keeping track of all immediates is created,
that can be increased on `setImmediate()` or decreased when an
immediate is run or cleared.
This is faster, because rather than reading/writing a C++ getter,
this operation can be performed as a direct memory read/write via
a typed array. The only C++ call that is left to make is
activating the native handles upon creation of the first
`Immediate` after the queue is empty.
One other (good!) side-effect is that `immediate._destroyed` now
reliably tells whether an `immediate` is still scheduled to run or not.
Also, as a nice extra, this should make it easier to implement
an internal variant of `setImmediate` for C++ that piggybacks
off the same mechanism, which should be useful at least for
async hooks and HTTP/2.
Benchmark results:
$ ./node benchmark/compare.js --new ./node --old ./node-master-1b093cb93df0 --runs 10 --filter immediate timers | Rscript benchmark/compare.R
[00:08:53|% 100| 4/4 files | 20/20 runs | 1/1 configs]: Done
improvement confidence p.value
timers/immediate.js type="breadth" thousands=2000 25.61 % ** 1.432301e-03
timers/immediate.js type="breadth1" thousands=2000 7.66 % 1.320233e-01
timers/immediate.js type="breadth4" thousands=2000 4.61 % 5.669053e-01
timers/immediate.js type="clear" thousands=2000 311.40 % *** 3.896291e-07
timers/immediate.js type="depth" thousands=2000 17.54 % ** 9.755389e-03
timers/immediate.js type="depth1" thousands=2000 17.09 % *** 7.176229e-04
timers/set-immediate-breadth-args.js millions=5 10.63 % * 4.250034e-02
timers/set-immediate-breadth.js millions=10 20.62 % *** 9.150439e-07
timers/set-immediate-depth-args.js millions=10 17.97 % *** 6.819135e-10
PR-URL: https://github.com/nodejs/node/pull/17064
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Worker threads need an event loop without active libuv handles in
order to shut down. One source of handles that was previously
not accounted for were delayed V8 tasks; these create timers
that would be standing in the way of clearing the event loop.
To solve this, keep track of the scheduled tasks in a list
and close their timer handles before the corresponding isolate/loop
is removed from the platform.
It is not clear from the V8 documentation what the expectation is
with respect to pending background tasks at the end of the
isolate lifetime; however, an alternative approach of executing
these scheduled tasks when flushing them led to an infinite loop
of tasks scheduling each other; so it seems safe to assume that
the behaviour implemented in this patch is at least acceptable.
Original-PR-URL: https://github.com/ayojs/ayo/pull/120
Original-Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
PR-URL: https://github.com/nodejs/node/pull/16700
Reviewed-By: James M Snell <jasnell@gmail.com>
Preparing for the migration of existing UVException and ErrnoExceptions
from the native layer, add new `errors.SystemError` to internal/errors
and new `env->CollectExceptionInfo()` / `env->CollectUVExceptionInfo()`
methods.
PR-URL: https://github.com/nodejs/node/pull/16567
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
CloudABI is a compact POSIX-like runtime that makes use of
capability-based security. More details:
https://github.com/NuxiNL/cloudlibc
* src: Disable use of pwd.h, grp.h and get*uid() on CloudABI.
As CloudABI is intended to run applications in cluster contexts (e.g.,
on Kubernetes), they are oblivious of UNIX credentials. Extend the
existing preprocessor checks to disable any use of these interfaces,
just like on Windows, Android, etc.
* src: Explicitly include <netdb.h>.
cares_wrap.cc calls into functions like getnameinfo() and getaddrinfo().
These functions tend to be available implicitly through <uv.h>, but we'd
better still include this header explicitly.
On CloudABI, we make use of a custom implementation of libuv that does
not implicitly include header files like <netdb.h>.
PR-URL: https://github.com/nodejs/node/pull/16612
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
This commit adds a method to internal/process that allows access to
bindings that are not intended to be used by user code. It has a
separate cache object and modlist in order to avoid collisions.
You can use NODE_MODULE_CONTEXT_AWARE_INTERNAL to register a C++
module as an internal.
PR-URL: https://github.com/nodejs/node/pull/15759
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
This enables a --loader flag for Node, which can provide custom
"resolve" and "dynamicInstantiate" methods for custom ES module
loading.
In the process, module providers have been converted from classes
into functions and the module APIs have been made to pass URL strings
over objects.
PR-URL: https://github.com/nodejs/node/pull/15445
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
While VM module's columnOffset option does succeed in applying an offset
to the column number in the stack trace, the wavy diagram printed does
not account for potential offsets, resulting in erroneous location of
`^` in the first line of the script.
Before:
```
> vm.runInThisContext('throw new Error()', { columnOffset: 5 })
evalmachine.<anonymous>:1
throw new Error()
^
Error
at evalmachine.<anonymous>:1:12
at ContextifyScript.Script.runInThisContext (vm.js:44:33)
at Object.runInThisContext (vm.js:116:38)
```
After:
```
> vm.runInThisContext('throw new Error()', { columnOffset: 5 })
evalmachine.<anonymous>:1
throw new Error()
^
Error
at evalmachine.<anonymous>:1:12
at ContextifyScript.Script.runInThisContext (vm.js:50:33)
at Object.runInThisContext (vm.js:139:38)
at repl:1:4
```
PR-URL: https://github.com/nodejs/node/pull/15771
Refs: https://github.com/tmpvar/jsdom/pull/2003
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
If bootstrap throws and if ids are added to the async id stack and if
the exception wasn't handled by the fatal exception handler then the
AsyncCallbackScope destructor will cause the AsyncHooks::pop_ids() stack
check to fail. Causing the application to crash. So clear the async id
stack manually.
This is only possible if the user: 1) manually calls MakeCallback() or
2) uses async await in the top level. Which will cause _tickCallback()
to fire before bootstrap finishes executing.
The following example shows how the application can fail due to
exceeding the maximum call stack while using async await:
async function fn() {
fn();
throw new Error();
}
(async function() { await fn(); })();
If this occurs during bootstrap then the application will pring the
following warning a number of times then exit with a status of 0:
(node:*) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: *): Error
Here's the same recursive call done after enabling a new AsyncHook() the
following will print instead of the above warning and exit with a
non-zero code (currently it's 7 because of how node::FatalException
assigns error codes based on where the failure happened):
script.js:25
async function fn() {
^
RangeError: Maximum call stack size exceeded
at <anonymous>
at fn (script.js:25:18)
at fn (script.js:26:3)
....
This has to do with how Promises lazily enable PromiseHook if an
AsyncHook() is enabled. Whether these need to be made uniform is outside
the scope of this commit
Fixes: https://github.com/nodejs/node/issues/15448
PR-URL: https://github.com/nodejs/node/pull/15553
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
V8 platform tasks may schedule other tasks (both background and
foreground), and may perform asynchronous operations like
resolving Promises.
To address that:
- Run the task queue drain call inside a callback scope.
This makes sure asynchronous operations inside it, like
resolving promises, lead to the microtask queue and any
subsequent operations not being silently forgotten.
- Move the task queue drain call before `EmitBeforeExit()`
and only run `EmitBeforeExit()` if there is no new event
loop work.
- Account for possible new foreground tasks scheduled by
background tasks in `DrainBackgroundTasks()`.
PR-URL: https://github.com/nodejs/node/pull/15428
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Matthew Loring <mattloring@google.com>
- Merge the two almost-but-not-quite identical `MakeCallback()`
implementations
- Provide a public `CallbackScope` class for embedders in order
to enable `MakeCallback()`-like behaviour without tying that
to calling a JS function
PR-URL: https://github.com/nodejs/node/pull/14697
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
`node_internals.h` already includes the most common headers,
so double includes can be avoided in a lot of cases. Also don’t include
`node_internals.h` from `node.h` implicitly anymore, as that is mostly
unnecessary.
PR-URL: https://github.com/nodejs/node/pull/14697
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Evan Lucas