René's URL Explorer Experiment

Title: worker: start worker threads from the built-in snapshot by codebytere · Pull Request #65336 · nodejs/node · GitHub

Open Graph Title: worker: start worker threads from the built-in snapshot by codebytere · Pull Request #65336 · nodejs/node

X Title: worker: start worker threads from the built-in snapshot by codebytere · Pull Request #65336 · nodejs/node

Description: new Worker() currently runs the whole internal bootstrap in the new isolate (realm, node, web exposure, the thread and process-state switches), compiling ~80 builtins with the code cache before internal/main/worker_thread starts. Only the main thread deserializes its principal context from the built-in snapshot, and that bootstrap is about half of a worker's cold start. The bootstrapped principal context in the snapshot is nearly thread-neutral already: is_not_main_thread.js and does_not_own_process_state.js are written as overrides of the main-thread switches, and the only thread-specific data baked into the context were six properties of the worker binding. This lets a worker deserialize the same kNodeMainContextIndex context and EnvSerializeInfo the main thread uses, and applies the two worker-side switches on top. misc/startup-core.js mode='worker' script='test/fixtures/semicolon.js' *** 98.45 % ±0.82% (21.1 -> 10.6 ms) misc/startup-core.js mode='worker' script='benchmark/fixtures/empty.mjs' *** 99.64 % ±0.60% misc/startup-core.js mode='worker' script='benchmark/fixtures/require-builtins.js' *** 47.58 % ±1.19% (33.8 -> 22.9 ms) misc/startup-core.js mode='worker' script='benchmark/fixtures/import-builtins.mjs' *** 30.03 % ±0.54% misc/startup-core.js mode='worker' script='test/fixtures/snapshot/typescript.js' *** 8.59 % ±0.46% misc/startup-core.js mode='process' (all five scripts) ±0.5 % n.s. (x64 Linux, 30 runs. An idle worker's RSS also drops from ~12.2 to ~8.1 MiB, heapTotal 8.6 to 5.4 MiB.) worker binding: threadId, threadName, isMainThread, isInternalThread, ownsProcessState and resourceLimits become lazy properties of the per-isolate template, computed from the Environment on first read, so no bootstrapped context carries them. Bootstrap itself only takes getEnvMessagePort from the binding. CreateEnvironment(): an empty context already means "deserialize from the snapshot". When the caller is a worker (its IsolateData has a Worker), deserialize the main context as before, then run internal/bootstrap/switches/is_not_main_thread and, unless the worker owns process state, does_not_own_process_state after InitializeMainContext(). Worker::Run(): take that path only when the snapshot in use is the embedded one (an embedder's own snapshot or a --snapshot-blob one has run application code in its main context, so it is never reused), browser globals aren't disabled (kNoBrowserGlobals changes the bootstrap shape) and --no-worker-snapshot wasn't passed. Otherwise the worker bootstraps from scratch as today, which is also the path for embedders that create environments without a snapshot. is_not_main_thread.js: also delete process._debugPause, _startProfilerIdleNotifier and _stopProfilerIdleNotifier, which is_main_thread.js installs. prepareExecution() runs the snapshot's deserialize callbacks (Buffer pool re-creation, the default resolver, cached cwd) on worker threads too, now that a worker's context can come from a snapshot; the --worker test suite caught a mis-aligned Buffer pool without it. --[no-]worker-snapshot per-isolate option, documented, as the escape hatch. Modules read no options at bootstrap time (getCLIOptionsValues() throws before bootstrapping is done and refreshOptions() runs in pre-execution), so a worker's execArgv can't disagree with anything captured in the context; per-thread runtime state (argv, execArgv, title, env proxy contents, time origin, inspector, message port, stdio) is established after context creation by Worker::Run() and prepareWorkerThreadExecution() as before. Testing: Object.getOwnPropertyNames() plus descriptor kinds of process and globalThis are identical between a from-snapshot and a --no-worker-snapshot worker, as are process listeners, features and versions. Same results as main for env: SHARE_ENV and copied env, resourceLimits, piped stdio, nested workers, eval/CJS/ESM/data: entries, exit codes, early terminate(), uncaught errors, structured-clone workerData, argv/execArgv/name, --frozen-intrinsics, --disable-proto=throw, the permission model, and a --build-snapshot user snapshot (workers do not see its globals). Full default suite on Release; tools/test.py --worker parallel (every parallel test inside a worker) passes except test-net-boundsocket, which fails the same way on main; worker, messageport, broadcastchannel, inspector-worker, async-hooks, process, bootstrap, snapshot and es-module suites on a Debug build (437/437). test-bootstrap-modules now expects the snapshot's module set in a snapshot-born worker. An earlier version added a dedicated worker context to the snapshot instead. Any second bootstrapped context in the node_mksnapshot isolate currently fails inside V8's serializer (SerializeBackingStore() on a typed array reached from both contexts, or CHECK(!SerializePendingObject(*code)) in VisitJSDispatchTableEntry()), so reusing the existing context is both the smaller change and the one that works today; i'll file the serializer limitation separately. Disclosure: the code, tests, measurements and this description were written by Claude Code, directed and reviewed by @codebytere.

Open Graph Description: new Worker() currently runs the whole internal bootstrap in the new isolate (realm, node, web exposure, the thread and process-state switches), compiling ~80 builtins with the code cache before int...

X Description: new Worker() currently runs the whole internal bootstrap in the new isolate (realm, node, web exposure, the thread and process-state switches), compiling ~80 builtins with the code cache before int...

Opengraph URL: https://github.com/nodejs/node/pull/65336

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width