When process exits, dump v8 isolate's internal stats for performance
evaluation and debugging.
It fixed the incorrect profiling log output when running V8's builtin
PGO profiling for node.js service type application,which exits by user
pressing CTRL+C etc. keys.
PR-URL: https://github.com/nodejs/node/pull/44534
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Context's default IsCodeGenerationFromStringsAllowed value can be
changed by v8 flag `--disallow-code-generation-from-strings`. Restore
the value at runtime when delegating the code generation validation to
`node::ModifyCodeGenerationFromStrings`.
The context's settings are serialized in the snapshot. Reset the setting
values to its default values before the serialization so that it can be
correctly re-initialized after deserialization at runtime.
PR-URL: https://github.com/nodejs/node/pull/44324
Fixes: https://github.com/nodejs/node/issues/44287
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Access to the global object from within a vm context is intercepted
so it's slow, therefore we should try to avoid unnecessary access
to it during the initialization of vm contexts.
- Remove the Atomics.wake deletion as V8 now does not install it
anymore.
- Move the Intl.v8BreakIterator deletion into the snapshot.
- Do not query the Object prototype if --disable-proto is not set.
This should speed up the creation of vm contexts by about ~12%.
PR-URL: https://github.com/nodejs/node/pull/44252
Refs: https://github.com/nodejs/node/issues/44014
Refs: https://github.com/nodejs/node/issues/37476
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
The term "native module" dates back to some of the oldest code
in the code base. Within the context of Node.js core it usually
refers to modules that are native to Node.js (e.g. fs, http),
but it can cause confusion for people who don't work on this
part of the code base, as "native module" can also refer to
native addons - which is even the case in some of the API
docs and error messages.
This patch tries to make the usage of these terms more consistent.
Now within the context of Node.js core:
- JavaScript scripts that are built-in to Node.js are now referred
to as "built-in(s)". If they are available as modules,
they can also be referred to as "built-in module(s)".
- Dynamically-linked shared objects that are loaded into
the Node.js processes are referred to as "addons".
We will try to avoid using the term "native modules" because it could
be ambiguous.
Changes in this patch:
File names:
- node_native_module.h -> node_builtins.h,
- node_native_module.cc -> node_builtins.cc
C++ binding names:
- `native_module` -> `builtins`
`node::Environment`:
- `native_modules_without_cache` -> `builtins_without_cache`
- `native_modules_with_cache` -> `builtins_with_cache`
- `native_modules_in_snapshot` -> `builtins_in_cache`
- `native_module_require` -> `builtin_module_require`
`node::EnvSerializeInfo`:
- `native_modules` -> `builtins
`node::native_module::NativeModuleLoader`:
- `native_module` namespace -> `builtins` namespace
- `NativeModuleLoader` -> `BuiltinLoader`
- `NativeModuleRecordMap` -> `BuiltinSourceMap`
- `NativeModuleCacheMap` -> `BuiltinCodeCacheMap`
- `ModuleIds` -> `BuiltinIds`
- `ModuleCategories` -> `BuiltinCategories`
- `LoadBuiltinModuleSource` -> `LoadBuiltinSource`
`loader.js`:
- `NativeModule` -> `BuiltinModule` (the `NativeModule` name used in
`process.moduleLoadList` is kept for compatibility)
And other clarifications in the documentation and comments.
PR-URL: https://github.com/nodejs/node/pull/44135
Fixes: https://github.com/nodejs/node/issues/44036
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Jan Krems <jan.krems@gmail.com>
This patch:
- Make NativeModuleLoader::LookupAndCompile() detect parameters based
on module IDs. This allows us to compile more builtins when
generating the embedded bootstrap, including
- internal/per_context/*
- internal/bootstrap/*
- internal/main/*
- Move pre_execution.js to lib/internal/process as it needs to be
compiled as a regular built-in module, unlike other scripts
in lib/internal/bootstrap
- Move markBootstrapComplete() to the performance binding instead of
making it a function-wrapper-based global to reduce number of
special cases.
PR-URL: https://github.com/nodejs/node/pull/44018
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This parameter was always being set to `nullptr` by its callers, either
explicitly or implicitly via the default argument. It was also buggy, as
in some cases it wouldn't be written to, potentially leaking stack
memory (see the early returns in `StringBytes::WriteUCS2`). Remove it
entirely.
PR-URL: https://github.com/nodejs/node/pull/44092
Reviewed-By: Feng Yu <F3n67u@outlook.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
According to the chrome trace event format document, works that
are performed on one single thread should be traced with sync
duration events. In this way, these events can be grouped under
one thread and the trace event viewer can estimate the CPU usage
of that thread.
PR-URL: https://github.com/nodejs/node/pull/42977
Reviewed-By: Darshan Sen <raisinten@gmail.com>
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>
daomingq