The binding data must be weak so that it won't keep the realm reachable
from strong GC roots indefinitely. The wrapper object of binding data
should be referenced from JavaScript, thus the binding data should be
reachable throughout the lifetime of the realm.
PR-URL: https://github.com/nodejs/node/pull/47688
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This PR is a follow-up of #46615.
When bumping V8 for node 18, various bugs appeared around vm.
Some have been fixed along the flow, but there is at least one
remaining and described at:
https://github.com/facebook/jest/issues/13338.
The current fix does nothing on node 20: the new bump of v8 done for
node 20 seems to fix it. But it would fix the problem in both node 18
and node 19. I confirmed it would fix node 19 by cherry-picking the
commit on v19.x-staging and launching `make -j4 jstest` on it.
PR-URL: https://github.com/nodejs/node/pull/47572
Reviewed-By: James M Snell <jasnell@gmail.com>
This patch makes the binding templates ObjectTemplates, since we
don't actually need the constructor function. This also avoids
setting the properties on prototype, and instead initializes them
directly on the object template.
Previously the initialization was similar to:
```
function Binding() {}
Binding.prototype.property = ...;
module.exports = new Binding;
```
Now it's similar to:
```
module.exports = { property: ... };
```
PR-URL: https://github.com/nodejs/node/pull/47913
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This patch moves the initialization of per-isolate properties of
the bindings that are in the embedded snapshot separate from the
initialization of their per-context properties. This is necessary
for workers to share the isolate snapshot with the main thread
and deserialize these properties instead of creating them from
scratch.
PR-URL: https://github.com/nodejs/node/pull/47768
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
Previously in the implementation there was a cycle that V8 could not
detect:
Strong global reference to CompiledFnEntry (JS wrapper)
-> strong reference to callback setting (through the
callbackMap key-value pair)
-> importModuleDynamically (wrapper in internalCompileFunction())
-> Strong reference to the compiled function (through closure in
internalCompileFunction())
The CompiledFnEntry only gets GC'ed when the compiled function is GC'ed.
Since the compiled function is always reachable as described above,
there is a leak.
We only needed the first strong global reference because we didn't want
the function to outlive the CompiledFnEntry. In this case it can be
solved by using a private symbol instead of going with the global
reference + destruction in the weak callback, which V8's GC is not
going to understand.
PR-URL: https://github.com/nodejs/node/pull/46785
Fixes: https://github.com/nodejs/node/issues/42080
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
A regression has been introduced in node 18.2.0,
it makes the following snippet fails while it used to work in the past:
```
const assert = require('assert');
const vm = require('vm');
const global = vm.runInContext('this', vm.createContext());
const totoSymbol = Symbol.for('toto');
Object.defineProperty(global, totoSymbol, {
enumerable: true,
writable: true,
value: 4,
configurable: true,
});
assert(Object.getOwnPropertySymbols(global).includes(totoSymbol));
```
Regression introduced by: https://github.com/nodejs/node/pull/42963.
So I basically attempted to start understanding what it changed to make
it fix the initial issue while not breaking the symbol related one.
Fixes: https://github.com/nodejs/node/issues/45983
PR-URL: https://github.com/nodejs/node/pull/46458
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Add experimental support for loading snapshots in the embedder API
by adding a public opaque wrapper for our `SnapshotData` struct and
allowing embedders to pass it to the relevant setup functions.
Where applicable, use these helpers to deduplicate existing code
in Node.js’s startup path.
This has shown a 40 % startup performance increase for a real-world
application, even with the somewhat limited current support for
built-in modules.
The documentation includes a note about no guarantees for API or
ABI stability for this feature while it is experimental.
PR-URL: https://github.com/nodejs/node/pull/45888
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Having this information available is useful for functions just as
it is for scripts. Therefore, expose it in the same way that other
information related to code caching is reported.
As part of this, de-duplify the code for setting the properties on
the C++ side and add proper exception handling to it.
PR-URL: https://github.com/nodejs/node/pull/46320
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
V8 already parses the source map magic comments. Currently, only scripts
and functions expose the parsed source map URLs. It is unnecessary to
parse the source map magic comments again when the parsed information is
available.
PR-URL: https://github.com/nodejs/node/pull/44798
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Jan Krems <jan.krems@gmail.com>
Instead of adding a reference to the ContextifyContext by using
a v8::External, we make ContextifyContext a weak BaseObject that
whose wrapper is referenced by the sandbox via a private symbol.
This makes it easier to snapshot the contexts, in addition to
reusing the BaseObject lifetime management for ContextifyContexts.
PR-URL: https://github.com/nodejs/node/pull/44796
Reviewed-By: Chengzhong Wu <legendecas@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>
Instead of creating an object template for every ContextifyContext,
we now create one object template that can be reused by all
contexts. The native pointer can be obtained through an embdder
pointer field in the creation context of the receiver in the
interceptors, because the interceptors are only meant to be invoked
on the global object of the contextified contexts. This makes
the ContextifyContext template context-independent and therefore
snapshotable.
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>
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>
Some embedders, like Electron, choose to start Node.js with
`only_terminate_in_safe_scope` set to `true`. In those cases, parts
of the API that expect execution termination to happen need to
be marked as able to receive those events. In our case, this is
the Ctrl+C support of the `vm` module (and Workers, but since
we’re in control of creating the `Isolate` for them, that’s a
non-concern there).
Add those scopes and add a regression test.
PR-URL: https://github.com/nodejs/node/pull/36344
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Gus Caplan <me@gus.host>
https://github.com/nodejs/node-v8/pull/147 broke the
`vm.measureMemory()` API. It only created a `MeasureMemoryDelegate` and
without actually calling `v8::Isolate::MeasureMemory()` so the returned
promise will never resolve. This was not caught by the tests because
the promise resolvers were not wrapped with `common.mustCall()`.
This patch migrates the API properly and also introduce the newly
added execution option to the API. It also removes support for
specifying contexts to measure - instead we'll just return the
measurements for all contexts in the detailed mode, which is
what the `performance.measureMemory()` prototype in V8 currently does.
We can consider implementing our own `v8::MeasureMemoryDelegate`
to select the target context in `ShouldMeasure()` in the future,
but then we'll also need to implement `MeasurementComplete()`
to assemble the result. For now it's probably too early to do that.
Since this API is still experimental (and guarded with a warning),
such breakage should be acceptable.
Refs: https://github.com/nodejs/node-v8/pull/147
PR-URL: https://github.com/nodejs/node/pull/32988
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
legendecas