For tests with subtests the before hook was being run after the
beforeEach hook, which is the opposite to test suites and expectations.
Also, a function was being used to close over the after hooks, but at
the point it was being run the after hooks were not yet set up.
Fixes#47915
PR-URL: https://github.com/nodejs/node/pull/47931
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
SKIP_CHECK_VALUE is a string literal, so its size is the length of the
string in chars plus one. The buffer buf is also always null-terminated,
so its size should match the size of SKIP_CHECK_VALUE, which is _not_
SKIP_CHECK_SIZE.
Rename SKIP_CHECK_SIZE to be consistent with C/C++ terminology.
PR-URL: https://github.com/nodejs/node/pull/47845
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Shelley Vohr <shelley.vohr@gmail.com>
Original commit message:
[wasm] Fix deadlock in async wrapper compilation
If compilation is cancelled while wrapper compilation is running, the
tasks spawned for the {AsyncCompileJSToWasmWrapperJob} will return
immediately, but {GetMaxConcurrency} will still return a positive
value. Hence {Join()} will spawn another task, resulting in a
livelock.
We could fix this by checking for cancellation in {GetMaxConcurrency},
but that requires taking the compilation state lock.
So this CL fixes the issue by dropping the number of outstanding
compilation units by to (basically) zero. We can't unconditionally drop
to zero because another thread might concurrently execute a wrapper
compilation and still call {CompleteUnit} afterwards. Hence only drop
outstanding units by the amount of not-yet-started units.
R=jkummerow@chromium.org
Bug: v8:13858
Change-Id: I5398ef370da2e7f212ca772fd1f87f659929dd6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4437531
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87143}
Refs: https://github.com/v8/v8/commit/5f025d1ca2ca2fe2f6cee5b6d841907a36fd32b7
PR-URL: https://github.com/nodejs/node/pull/47610
Refs: https://github.com/nodejs/node/issues/47297
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently we use external strings for internalized builtin source code.
However when a snapshot is taken, any external string whose resource
is not registered is flattened into a SeqString (see ref). The
result is that module source code stored in the snapshot does not
use external strings after deserialization. This patch registers an
external string resource for each internalized builtin's source. The
savings are substantial: ~1.9 MB of heap memory per isolate, or ~44%
of an otherwise empty isolate's heap usage:
```console
$ node --expose-gc -p 'gc(),process.memoryUsage().heapUsed'
4190968
$ ./node --expose-gc -p 'gc(),process.memoryUsage().heapUsed'
2327536
```
The savings can be even higher for user snapshots which may include
more internal modules.
The existing UnionBytes implementation was ill-suited, because it only
created an external string resource when ToStringChecked was called,
but we need to register the external string resources before the
isolate even exists. We change UnionBytes to no longer own the data,
and shift ownership of the data to a new external resource class
called StaticExternalByteResource. StaticExternalByteResource are
either statically allocated (for internalized builtin code) or owned
by the static `externalized_builtin_sources` map, so they will only be
destructed when static resources are destructed. We change JS2C to emit
statements to register a string resource for each internalized builtin.
Refs: https://github.com/v8/v8/blob/d2c8fbe9ccd1a6ce5591bb7dd319c3c00d6bf489/src/snapshot/serializer.cc#L633
PR-URL: https://github.com/nodejs/node/pull/47055
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
The code cache is quite large - around 1.3 MiB. Change the code to use
non-owning buffers to avoid copying it. For starting up an otherwise
empty main isolate, this saves around 1.3 MiB of unique set size memory
(9.9 MiB -> 8.6 MiB) and 1.1ms elapsed time (22.9 ms -> 21.8 ms).
Copying the code cache is unnecessary since:
1. for the builtin snapshot, the code cache data has static lifetime.
2. for non-builtin snapshots, we create copies of the code cache data in
`SnapshotDeserializer::ReadVector`. These copies are owned by the
`Environment` (through `IsolateData` -> `SnapshotData`), so they
won't be deallocated.
3. a worker thread can copy a parent's isolate's code cache, but in that
case we still know that the parent isolate will outlive the worker
isolate.
(Admittedly point (2) feels a little fragile from a lifetime
perspective, and I would be happy to restrict this optimization to the
builtin snapshot.)
```console
$ perf stat -r 100 -e ... ./node -e 0
Performance counter stats for './node -e 0' (100 runs):
21.78 msec task-clock
2760 page-faults
113161604 instructions
18437648 branches
423230 branch-misses
853093 cache-references
41474 cache-misses
0.0225473 +- 0.0000504 seconds time elapsed ( +- 0.22% )
$ perf stat -r 100 -e ... ./node-main -e 0
Performance counter stats for './node-main -e 0' (100 runs):
22.91 msec task-clock
3102 page-faults
114890673 instructions
18751329 branches
428909 branch-misses
895721 cache-references
45202 cache-misses
0.0233760 +- 0.0000741 seconds time elapsed ( +- 0.32% )
```
PR-URL: https://github.com/nodejs/node/pull/47144
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
The http2 implementation uses the deprecated function
nghttp2_session_callbacks_set_error_callback, which does not supply an
error code but only an error message. This so far forced node's error
callback to rely on the error message in order to distinguish between
different errors, which is fragile and inefficient.
Use the newer nghttp2_session_callbacks_set_error_callback2 function
instead, which is not deprecated and which provides the exact error code
to node's error callback.
PR-URL: https://github.com/nodejs/node/pull/47840
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
The HTML StructuredSerializeWithTransfer algorithm defines that when
an untransferable object is in the transfer list, a DataCloneError is
thrown.
An array buffer that is already transferred is also considered as
untransferable.
PR-URL: https://github.com/nodejs/node/pull/47604
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>