Files
node/test
Robert Nagy 6dea43a0f8 lib: speed up AbortSignal
Speed up creating and aborting signals, adding and removing abort
listeners, AbortSignal.any() and AbortSignal.timeout(), and stop the
default abort reason from retaining the aborting caller.

- Only allocate and dispatch the abort event when the signal has abort
  listeners, and only allocate the dependent signal list when there
  are dependent signals.
- Track whether an event is trusted with a private field instead of a
  WeakSet.
- Flatten addEventListener() options into locals instead of
  allocating a normalized options object, only validate the signal
  option when one is passed, and use the listener flags directly.
- Call the EventTarget kNewListener and kRemoveListener
  implementations directly. V8 does not optimize keyed super property
  access such as super[kNewListener]().
- Initialize the internal slots that AbortSignal.any() adds to its
  sources up front, and the composite-only slots for composites, so
  live signals don't change shape.
- Give every signal a single WeakRef that is shared by all the
  composites that follow it, and register each composite and each
  source once with their cleanup registries instead of registering
  every (source, composite) pair with an unregister token. Registering
  with an unregister token is several times more expensive.
- Register AbortSignal.timeout() timers through a holder that is
  emptied when the timer fires, instead of using the signal as an
  unregister token.
- Take positional arguments in AbortSignal's internal constructor
  instead of destructuring an options object that defaults to
  kEmptyObject. kEmptyObject is a null-prototype object, which V8 keeps
  in dictionary mode, so each of those reads was an uncached dictionary
  miss that cost more than the rest of the constructor.
- Create the default abort reason with Error.stackTraceLimit set to 0.
  Until a captured stack is formatted, V8 keeps the call sites, which
  retain the receivers and functions of the aborting caller's frames,
  so a retained signal kept the aborted work alive. Formatting the
  stack eagerly would fix that but costs several microseconds per
  abort(). The default AbortError no longer shows where abort() was
  called; callers that want that can pass their own reason.
- Add benchmarks for aborting, adding and removing abort listeners,
  and AbortSignal.any().

Refs: https://github.com/nodejs/node/issues/66192
Refs: https://github.com/nodejs/node/pull/66265
Assisted-by: claude:opus-5.5
Signed-off-by: Robert Nagy <ronagy@icloud.com>
PR-URL: https://github.com/nodejs/node/pull/66789
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
2026-10-24 19:17:24 +00:00
..
2026-10-15 00:52:34 +00:00
2026-10-24 19:17:24 +00:00
…
2026-10-24 19:17:24 +00:00
2026-10-20 12:33:08 +00:00
…

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.

  1. Documentation ↩︎

  2. Tests for networking related modules may also be present in other directories, but those tests do not make outbound connections. ↩︎

  3. 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. ↩︎

  4. The tests are for the logic in lib/internal/main/prof_process.js and lib/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. ↩︎