The existing code explicitly uses the CID(const ngtcp2_cid*) constructor
that does not copy the given ngtcp2_cid, but the range-based for loop
still unnecessarily copies the ngtcp2_cid. Use auto& to avoid copying.
PR-URL: https://github.com/nodejs/node/pull/48561
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48540
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
The `writable._write()` implementation does not need to return anything,
only call the callback.
PR-URL: https://github.com/nodejs/node/pull/48526
Reviewed-By: Keyhan Vakil <kvakil@sylph.kvakil.me>
Reviewed-By: Debadree Chatterjee <debadree333@gmail.com>
Reviewed-By: Deokjin Kim <deokjin81.kim@gmail.com>
Setting the `maxConnections` to 0 should result in no connection.
Instead, it was treated as if the option was not there.
PR-URL: https://github.com/nodejs/node/pull/48276
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
PR-URL: https://github.com/nodejs/node/pull/47653
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
this is currently for internal use only,
with a synchrnous API.
PR-URL: https://github.com/nodejs/node/pull/47653
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
This ensures that we only create one IsolateData for each isolate
inthe cctest, since IsolateData are meant to be per-isolate.
We need to make the isolate and isolate_data static in the
test fixtures as a result, similar to how the event loops and
array buffer allocators are managed in the
NodeZeroIsolateTestFixture but it is fine because gtest ensures
that the Setup() and TearDown() of the fixtures are always run
in order and would never overlap in one process.
PR-URL: https://github.com/nodejs/node/pull/48450
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Speed up child_process.spawn by enabling the new V8 build flag which
makes fork/exec faster.
Here are the results of running the existing benchmark. Note that this
optimization helps more for applications with larger heaps, so this is
somewhat of an underestimate of the real world performance benefits.
```console
$ ./node benchmark/compare.js --runs 15 \
--new ./node \
--old ~/node-v20/out/Release/node \
--filter params child_process > cpr
$ node-benchmark-compare cpr
confidence improvement (***)
methodName='exec' n=1000 *** 60.84 % ±5.43%
methodName='execFile' n=1000 *** 53.72 % ±3.33%
methodName='execFileSync' n=1000 *** 9.10 % ±0.84%
methodName='execSync' n=1000 *** 10.44 % ±0.97%
methodName='spawn' n=1000 *** 53.10 % ±2.90%
methodName='spawnSync' n=1000 *** 8.64 % ±1.22%
0.01 false positives, when considering a 0.1% risk acceptance (***)
```
Fixes: https://github.com/nodejs/node/issues/25382
Fixes: https://github.com/nodejs/node/issues/14917
Refs: https://github.com/nodejs/performance/issues/93
Refs: https://github.com/nodejs/performance/issues/89
PR-URL: https://github.com/nodejs/node/pull/48523
Refs: 1a782f6543
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Debadree Chatterjee <debadree333@gmail.com>
Original commit message:
[base] add build flag to use MADV_DONTFORK
Embedders like Node.js and Electron expose fork(2)/execve(2) to their
users. Unfortunately when the V8 heap is very large, these APIs become
rather slow on Linux, due to the kernel needing to do all the
bookkeeping for the forked process (in clone's dup_mmap and execve's
exec_mmap). Of course, this is useless because the forked child thread
will never actually need to access the V8 heap.
Add a new build flag v8_enable_private_mapping_fork_optimization which
marks all pages allocated by OS::Allocate as MADV_DONTFORK. This
improves the performance of Node.js's fork/execve combination by 10x on
a 600 MB heap.
Fixed: v8:7381
Change-Id: Ib649f774d4a932b41886313ce89acc369923699d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4602858
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88447}
Refs: 1a782f6543
PR-URL: https://github.com/nodejs/node/pull/48523
Fixes: https://github.com/nodejs/node/issues/25382
Fixes: https://github.com/nodejs/node/issues/14917
Refs: https://github.com/nodejs/performance/issues/93
Refs: https://github.com/nodejs/performance/issues/89
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Debadree Chatterjee <debadree333@gmail.com>
Include node.h first to define NAPI_VERSION that node binary is built
with. The node.h should also be included first in embedder's use case
since it is the primary header file.
PR-URL: https://github.com/nodejs/node/pull/48376
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Incremental compilation of Node.js is slow. Currently on a powerful
Linux machine, it takes about 9 seconds and 830 MB of memory to compile
`gen/node_javascript.cc` with g++. This is the longest step when
recompiling a small change to a Javascript file.
`gen/node_javascript.cc` contains a lot of large binary literals of our
Javascript source code. It is well-known that embedding large binary
literals as C/C++ arrays is slow. One workaround is to include the data
as string literals instead. This is particularly nice for the Javascript
included via js2c, which look better as string literals anyway.
Add a build flag `NODE_JS2C_USE_STRING_LITERALS` to js2c. When this flag
is set, we emit string literals instead of array literals, i.e.:
```c++
// old: static const uint8_t X[] = { ... };
static const uint8_t *X = R"JS2C1b732aee(...)JS2C1b732aee";
// old: static const uint16_t Y[] = { ... };
static const uint16_t *Y = uR"JS2C1b732aee(...)JS2C1b732aee";
```
This requires some modest refactoring in order to deal with the flag
being on or off, but the new code itself is actually shorter.
I only enabled the new flag on Linux/macOS, since those are systems that
I have available for testing. On my Linux system with gcc, it speeds up
compilation by 5.5s (9.0s -> 3.5s). On my Mac system with clang, it
speeds up compilation by 2.2s (3.7s -> 1.5s). (I don't think this flag
will work with MSVC, but it'd probably speed up clang on windows.)
The long-term goal here is probably to allow this to occur incrementally
per Javascript file & in parallel, to avoid recompiling all of
`gen/node_javascript.cc`. Unfortunately the necessary gyp incantations
seem impossible (or at least, far beyond me). Anyway, a 60% speedup is a
nice enough win.
Refs: https://github.com/nodejs/node/issues/47984
PR-URL: https://github.com/nodejs/node/pull/48160
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48513
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Harshitha K P <harshitha014@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48492
Refs: https://github.com/nodejs/performance/issues/92
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48032
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mestery <mestery@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This adds the `SourceMap.findOrigin(lineNumber, columnNumber)` method,
for finding the origin source file and 1-indexed line and column numbers
corresponding to the 1-indexed line and column numbers from a call site
in generated source code.
Fix: #47770
PR-URL: https://github.com/nodejs/node/pull/47790
Fixes: https://github.com/nodejs/node/issues/47770
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
PR-URL: https://github.com/nodejs/node/pull/48508
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48502
Reviewed-By: Debadree Chatterjee <debadree333@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
PR-URL: https://github.com/nodejs/node/pull/48491
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/48481
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Matthew Aitken <maitken033380023@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Qingyu Deng <i@ayase-lab.com>
PR-URL: https://github.com/nodejs/node/pull/48514
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48473
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Nitzan Uziely <linkgoron@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
New versions have new rules and end up breaking builds unexpectedly.
PR-URL: https://github.com/nodejs/node/pull/48505
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Ruy Adorno <ruyadorno@google.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Geoffrey Booth <webadmin@geoffreybooth.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/48494
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
When attempting to convert the SPKI of a X509Certificate to a KeyObject,
throw an error if the subjectPublicKey cannot be parsed instead of
aborting the process.
Fixes: https://hackerone.com/bugs?report_id=1884159
PR-URL: https://github.com/nodejs-private/node-private/pull/393
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
CVE-ID: CVE-2023-30588
