mirror of
https://github.com/nodejs/node.git
synced 2026-11-09 15:11:11 -05:00
Shelley Vohr
26bd28cbdb
Environments created from the built-in snapshot get the builtins' code cache from that snapshot. An embedder that bootstraps an Environment from scratch (its own isolate and context, no EmbedderSnapshotData) has no way to provide one: every builtin the bootstrap touches is compiled from source in every such process, and each of them then serializes a fresh cache (SaveCodeCache) that only a later worker thread would ever consume. Add node::EmbedderBuiltinCodeCache for that case. Its entries pair a builtin id with a v8::ScriptCompiler::CachedData; Generate(context) compiles every builtin in a context of the right kind of isolate and returns them for a build step to embed, and SetBuiltinCodeCache(isolate_data, cache) attaches them to an IsolateData, next to where a snapshot's code cache lives, so that every Environment created from it afterwards starts with them. The setter runs CachedData::CompatibilityCheck() against the isolate first and returns the result, leaving the IsolateData untouched for a cache made with another V8 version, flag set or read-only snapshot. Entries from a snapshot still merge with it (RefreshCodeCache() now merges instead of assuming a single call). CreateEnvironment() plus LoadEnvironment() of an empty script goes from about 38 ms to 13 ms with a cache attached. ProcessInitializationFlags::kNoHarvestBuiltinCodeCache stops serializing caches for builtins compiled without one, for embedders that supply their own or never create workers. The default is unchanged because worker threads copy the harvested cache. A cctest generates a cache, attaches it, checks that a new Environment's bootstrap compiles from it and that a corrupted cache is refused; embedtest gains --no-harvest-builtin-code-cache for a test that a worker does or does not find a harvested cache depending on the flag. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: https://github.com/nodejs/node/pull/65352 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Node.js Core Tests
This directory contains code and data used to test the Node.js implementation.
For a detailed guide on how to write tests in this directory, see the guide on writing tests.
On how to run tests in this directory, see the contributing guide.
For the tests to run on Windows, be sure to clone Node.js source code with the
autocrlf git config flag set to true.
Test Directories
| Directory | Runs on CI | Purpose |
|---|---|---|
abort |
Yes | Tests that use --abort-on-uncaught-exception and other cases where we want to avoid generating a core file. |
addons |
Yes | Tests for addon functionality along with some tests that require an addon. |
async-hooks |
Yes | Tests for async_hooks functionality. |
benchmark |
Yes | Test minimal functionality of benchmarks. |
cctest |
Yes | C++ tests that are run as part of the build process. |
code-cache |
No | Tests for a Node.js binary compiled with V8 code cache. |
common |
N/A | Common modules shared among many tests.1 |
doctool |
Yes | Tests for the documentation generator. |
es-module |
Yes | Test ESM module loading. |
fixtures |
N/A | Test fixtures used in various tests throughout the test suite. |
internet |
No | Tests that make real outbound network connections.2 |
js-native-api |
Yes | Tests for Node.js-agnostic Node-API functionality. |
known_issues |
Yes | Tests reproducing known issues within the system.3 |
message |
Yes | Tests for messages that are output for various conditions |
node-api |
Yes | Tests for Node.js-specific Node-API functionality. |
parallel |
Yes | Various tests that are able to be run in parallel. |
pseudo-tty |
Yes | Tests that require stdin/stdout/stderr to be a TTY. |
pummel |
No | Various tests for various modules / system functionality operating under load. |
sequential |
Yes | Various tests that must not run in parallel. |
testpy |
N/A | Test configuration utility used by various test suites. |
tick-processor |
No | Tests for the V8 tick processor integration.4 |
v8-updates |
No | Tests for V8 performance integration. |
-
Tests for networking related modules may also be present in other directories, but those tests do not make outbound connections. ↩︎
-
All tests inside of this directory are expected to fail. If a test doesn't fail on certain platforms, those should be skipped via
known_issues.status. ↩︎ -
The tests are for the logic in
lib/internal/main/prof_process.jsandlib/internal/v8_prof_polyfill.js. The tests confirm that the profile processor packages the correct set of scripts from V8 and introduces the correct platform specific logic. ↩︎