When "vfsArchive" names a ZIP archive in the SEA configuration (with
"useVfs": true), --build-sea embeds the archive verbatim as one
reserved asset, and at runtime the SEA virtual file system mounts the
existing ZipProvider over a zero-copy view of the embedded archive
instead of the SEAProvider. The main script is injected into the
in-memory archive index as a stored entry, so the mounted tree looks
the same as with "assets".
The archive can be produced with any ZIP tool or with the ZIP support
in node:zlib; no ZIP serialization logic is added to the build side.
This trades asset read speed (entries are inflated when opened) for a
substantially smaller executable when the assets are compressible.
Also make FindSingleExecutableResource() return the deserialized
SeaResource by reference instead of by value: the copy included the
whole assets map, and getAsset() calls it once per asset read, so
every fs operation served by the SEA virtual file system paid a cost
linear in the number of bundled assets - with 8192 assets, reading
each of them took seconds instead of milliseconds.
Signed-off-by: Matteo Collina <hello@matteocollina.com>
PR-URL: https://github.com/nodejs/node/pull/65810
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
This adds a embedder_module_hdo for identifying embedder-run
modules in the dynamic import handler and import.meta initializer,
and a SourceTextModuleTypes for customizing source text module
compilation in the JS land via compileSourceTextModule().
Also, refactors the existing embedder module compilation code
to reuse the builtin resolution logic.
PR-URL: https://github.com/nodejs/node/pull/61654
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Aditi Singh <aditisingh1400@gmail.com>
It's been a bit of a code smell that we create these objects in
different conditional branches, effectively forcing ourselves to
duplicate logic between those branches.
This code predates `std::optional` being available to us, but
now that it is, it's the idiomatic way to resolve this issue.
(This commit also explicitly deletes move and copy members for
these classes; these had previously been omitted for brevity,
but adding them made me feel more confident that there is no
hidden copy operation added through this change.)
PR-URL: https://github.com/nodejs/node/pull/59960
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
As V8 is moving towards built-in CppHeap creation, change the
management so that the automatic CppHeap creation on Node.js's end
is also enforced at Isolate creation time.
1. If embedder uses NewIsolate(), either they use
IsolateSettings::cpp_heap to specify a CppHeap that will be owned
by V8, or if it's not configured, Node.js will create a CppHeap
that will be owned by V8.
2. If the embedder uses SetIsolateUpForNode(),
IsolateSettings::cpp_heap will be ignored (as V8 has deprecated
attaching CppHeap post-isolate-creation). The embedders need to
ensure that the v8::Isolate has a CppHeap attached while it's
still used by Node.js, preferably using v8::CreateParams.
See https://issues.chromium.org/issues/42203693 for details. In
future version of V8, this CppHeap will be created by V8 if not
provided, and we can remove our own "if no CppHeap provided,
create one" code in NewIsolate().
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This simplifies the memory management of ContextifyContext,
making all references visible to V8.
The destructors don't need to do anything because when the wrapper is
going away, the context is already going away or otherwise it would've
been holding the wrapper alive, so there's no need to reset the
pointers in the context. Also, any global handles to the context
would've been empty at this point, and the per-Environment context
tracking code is capable of dealing with empty handles from contexts
purged elsewhere.
To this end, the context tracking code also purges empty handles
from the list now, to prevent keeping too many empty handles around.
PR-URL: https://github.com/nodejs/node/pull/56522
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
V8 introduced `v8::LocalVector` somewhat recently as an alternative
to using `std::vector<v8::Local<T>>` to help ensure that Local handles
are handled correctly. This updates most (but not all) of our uses
of `std::vector<v8::Local<T>>` to use `v8::LocalVector<T>` with a few
other minor cleanups encountered along the way.
PR-URL: https://github.com/nodejs/node/pull/56417
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Property enumerator methods like `Object.getOwnPropertyNames`,
`Object.getOwnPropertySymbols`, and `Object.keys` all invokes the
named property enumerator interceptor. V8 will filter the result based
on the invoked enumerator variant. Fix the enumerator interceptor to
return all potential properties.
PR-URL: https://github.com/nodejs/node/pull/54522
Refs: https://github.com/jsdom/jsdom/issues/3688
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This implements a flavor of vm.createContext() and friends
that creates a context without contextifying its global object.
This is suitable when users want to freeze the context (impossible
when the global is contextified i.e. has interceptors installed)
or speed up the global access if they don't need the interceptor
behavior.
```js
const vm = require('node:vm');
const context = vm.createContext(vm.constants.DONT_CONTEXTIFY);
// In contexts with contextified global objects, this is false.
// In vanilla contexts this is true.
console.log(vm.runInContext('globalThis', context) === context);
// In contexts with contextified global objects, this would throw,
// but in vanilla contexts freezing the global object works.
vm.runInContext('Object.freeze(globalThis);', context);
// In contexts with contextified global objects, freezing throws
// and won't be effective. In vanilla contexts, freezing works
// and prevents scripts from accidentally leaking globals.
try {
vm.runInContext('globalThis.foo = 1; foo;', context);
} catch(e) {
console.log(e); // Uncaught ReferenceError: foo is not defined
}
console.log(context.Array); // [Function: Array]
```
PR-URL: https://github.com/nodejs/node/pull/54394
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
This patch:
1. Refactor the routines used to compile and run an embedder
entrypoint. In JS land special handling for SEA is done
directly in main/embedding.js instead of clobbering the CJS
loader. Add warnings to remind users that currently the
require() in SEA bundled scripts only supports loading builtins.
2. Don't use the bundled SEA code cache when compiling CJS
loaded from disk, since in that case we are certainly not
compiling the code bundled into the SEA. Use a is_sea_main
flag in CompileFunctionForCJSLoader() (which replaces an unused
argument) to pass this into the C++ land - the code cache is
still read directly from C++ to avoid the overhead of
ArrayBuffer creation.
3. Move SEA loading code into
MaybeLoadSingleExecutableApplication() which calls
LoadEnvironment() with its own StartExecutionCallback().
This avoids more hidden switches in StartExecution() and
make them explicit. Also add some TODOs about how to support
ESM in embedded applications.
4. Add more comments
PR-URL: https://github.com/nodejs/node/pull/53573
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
