This overload accepts the current Environment* as an argument, unlike
the other constructor, which accepts an Isolate*. This is useful because
we can pass the current Environment* directly instead of recomputing it
from the Isolate* inside the constructor.
Signed-off-by: Darshan Sen <darshan.sen@postman.com>
PR-URL: https://github.com/nodejs/node/pull/39768
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
For certain embedder use cases there are more complex memory allocation
requirements that the default V8 page allocator does not handle.
For example, using MAP_JIT when running under a hardened runtime
environment on macOS. This allows embedders like Electron to provide
their own allocator that does handle these cases.
PR-URL: https://github.com/nodejs/node/pull/38362
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
With this change, the V8 profiler will attribute any time between
prepare and check cycles, except any entrances to InternalCallbackScope,
to be "idle" time. All callbacks, microtasks, and timers will be marked
as not idle. The one exception is native modules which don't use the
MakeCallback helper, but those are already broken anyway for async
context tracking so we should just encourage broken modules to be fixed.
PR-URL: https://github.com/nodejs/node/pull/37868
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Node.js sets a stack trace handler specific to the v8::Context
corresponding to the current Environment. When Electron is running in a
non-Node.js v8::Context (e.g in the renderer process with
contextIsolation enabled), there will be no correspondent Environment -
we therefore need to prevent this handler being set so that Blink falls
back to its default handling and displays the correct stacktrace.
PR-URL: https://github.com/nodejs/node/pull/36447
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
There are situations where one wants to invoke a JS callback's ->Call()
from C++ and in particular retain any existing async_context state, but
where it's not obvious that a plain ->Call() would be safe at the point
in question.
Such callsites usually resort to
node::MakeCallback(..., async_context{0, 0}), which unconditionally
pushes the async_context{0, 0} and takes the required provisions for the
->Call() itself such as triggering the tick after its return, if needed.
An example would be the PerformanceObserver invocation from
PerformanceEntry::Notify(): this can get called when coming from JS
through e.g. perf_hooks.performance.mark() and alike, but perhaps also
from nghttp2 (c.f. EmitStatistics() in node_http2.cc).
In the former case, a plain ->Call() would be safe and it would be
desirable to retain the current async_context so that
PerformanceObservers can access it resp. the associated
AsyncLocalStorage. However, in the second case the additional provisions
taken by node::MakeCallback() might potentially be strictly required.
So PerformanceEntry::Notify() bites the bullet and invokes the
PerformanceObservers through node::MakeCallback() unconditionally,
thereby always rendering any possibly preexisting async_context
inaccessible.
Introduce the convenience node::MakeSyncCallback() for such usecases,
which would basically forward to ->Call() if safe and to
node::MakeCallback(..., async_context{0, 0}) otherwise.
Co-Authored-By: ZauberNerd <zaubernerd@zaubernerd.de>
PR-URL: https://github.com/nodejs/node/pull/36343
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Provide helpers for a) spinning the event loop and
b) setting up and tearing down the objects involved in a single
Node.js instance, as they would typically be used.
The former helper is also usable inside Node.js itself,
for both Worker and main threads.
PR-URL: https://github.com/nodejs/node/pull/35597
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
This call can fail, we should not use `.ToLocalChecked()` here.
In the long run, we should use variants of `EmitExit()` and
`EmitBeforeExit()` that avoid this problem by properly propagating
empty `MaybeLocal`s.
Example failure:
21:07:17 not ok 2564 parallel/test-worker-terminate-source-map
21:07:17 ---
21:07:17 duration_ms: 0.385
21:07:17 severity: crashed
21:07:17 exitcode: -6
21:07:17 stack: |-
21:07:17 FATAL ERROR: v8::ToLocalChecked Empty MaybeLocal.
21:07:17 1: 0x1012f04a5 node::Abort() (.cold.1) [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/node]
21:07:17 2: 0x1000b52d9 node::Abort() [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/node]
21:07:17 3: 0x1000b543f node::OnFatalError(char const*, char const*) [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/node]
21:07:17 4: 0x1001ffd70 v8::V8::ToLocalEmpty() [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/node]
21:07:17 5: 0x1000079b8 node::EmitBeforeExit(node::Environment*) [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/node]
21:07:17 6: 0x100156fea node::worker::Worker::Run() [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/node]
21:07:17 7: 0x10015a4d2 node::worker::Worker::StartThread(v8::FunctionCallbackInfo<v8::Value> const&)::$_3::__invoke(void*) [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/node]
21:07:17 8: 0x7fff72fe7109 _pthread_start [/usr/lib/system/libsystem_pthread.dylib]
21:07:17 9: 0x7fff72fe2b8b thread_start [/usr/lib/system/libsystem_pthread.dylib]
21:07:17 ...
PR-URL: https://github.com/nodejs/node/pull/35484
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
The `set_abort_on_uncaught_exception(false)` line was supposed to
prevent aborting when running Workers in
`--abort-on-uncaught-exception` mode, but it was incorrectly set
and not checked properly in the should-abort callback.
PR-URL: https://github.com/nodejs/node/pull/34724
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Mary Marchini <oss@mmarchini.me>
I added it in commit 57231d5286 ("src: notify V8 profiler when we're
idle") from October 2013 as a stop-gap measure to measure CPU time
rather than wall clock time, otherwise processes that spend a lot
of time sleeping in system calls give a false impression of being
very busy.
That fix is not without drawbacks because the idle flag is set before
libuv makes I/O callbacks and cleared again after. I/O callbacks can
result into calls into JS code and executing JS code is as non-idle
as you can get.
In commit 96ffcb9a21 ("src: reduce cpu profiler overhead") from January
2015, I made Node.js block off the SIGPROF signal that V8's CPU profiler
uses before Node.js goes to sleep. The goal of that commit is to reduce
the overhead from EINTR system call wakeups but it also has the pleasant
side effect of fixing what the idle notifier tried to fix.
This commit removes the idle notifier and turns the JS process object
methods into no-ops.
Fixes: https://github.com/nodejs/node/issues/19009
Refs: https://github.com/nodejs/node/pull/33138
PR-URL: https://github.com/nodejs/node/pull/34010
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
"utf-16LE" was parsed "UNKNOWN", this fixes to "UCS2"
"utf-buffer" was parsed "BUFFER", this fixes to "UNKNOWN"
"utf-16leNOT" was parsed "UCS2", this fixes to "UNKNOWN"
PR-URL: https://github.com/nodejs/node/pull/33957
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
This addresses a TODO comment, and aligns the behavior between
worker threads and the main thread.
The primary motivation for this change is to more strictly enforce
the invariant that no JS runs after the `'exit'` event is emitted.
PR-URL: https://github.com/nodejs/node/pull/33874
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
This commit suggests using MaybeLocal::FromMaybe to return the exception
string, passing in a default value (an empty Local<Value>) which will be
used if the exception object is empty.
PR-URL: https://github.com/nodejs/node/pull/33514
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Use a symbol on the bindings object to store the public resource object,
rather than a `v8::Global` Persistent. This has several advantages:
- It’s harder to inadvertently create memory leaks this way.
The garbage collector sees the `AsyncWrap` → resource link like
a regular JS property, and can collect the objects as a group,
even if the resource object should happen to point back to the
`AsyncWrap` object.
- This will make it easier in the future to use `owner_symbol` for
this purpose, which is generally the direction we should be moving
the `async_hooks` API into (i.e. using more public objects instead
of letting internal wires stick out).
PR-URL: https://github.com/nodejs/node/pull/31745
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Termination exceptions are similar to uncaught exceptions in that they
should clear the async id stack, because no ongoing async callbacks
will be brought to completion when execution terminates.
Previously, there was a check that made sure that that happened when
the termination occurred during the callback itself, but no such check
was in place for the case that the termination occurred during
microtasks started by them. This commit adds such a check, both for
microtasks and the `nextTick` queue. The latter addition doesn’t fix
a crash, but still makes sense conceptually.
The condition here is also flipped from applying only on Worker threads
to also applying on the main thread, and setting the `failed_` flag
rather than reading it. The former makes sense because the public C++
`Stop(env)` API can have the same effect as worker thread termination,
but on the main thread rather than a Worker thread.
PR-URL: https://github.com/nodejs/node/pull/33347
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Anna Henningsen