PR-URL: https://github.com/nodejs/node/pull/28118
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/28071
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Refael Ackermann (רפאל פלחי) <refack@gmail.com>
- ICU uses sha512 instead of md5 in some recent releases
- Use hashlib.algorithms_guaranteed to choose the following algorithms:
sha1 sha224 sha384 sha256 sha512 md5
- No preference as to the priority of the algorithms
- This commit does not change the hash used for ICU.
Fixes: https://github.com/nodejs/node/issues/27369
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-by: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-by: Richard Lau <riclau@uk.ibm.com>
PR-URL: https://github.com/nodejs/node/pull/27370
* Add symlink from Release to out\Release for backward compat
PR-URL: https://github.com/nodejs/node/pull/27149
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
The check that the user specified `icu` in `--download` only needs to be
done once and not for each entry in `tools/icu/current_ver.dep`.
Fixes: https://github.com/nodejs/node/issues/26860
PR-URL: https://github.com/nodejs/node/pull/27031
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Normalized boolean options in the gypfiles for consistency both
internally and with the V8 GN config.
Co-authored-by: Michaël Zasso <targos@protonmail.com>
PR-URL: https://github.com/nodejs/node/pull/26685
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Triggers the V8_USE_SIPHASH to switch from the internal custom V8
hash seed generation function to an implementation of SipHash. Final
step needed to clear up HashWick.
PR-URL: https://github.com/nodejs/node/pull/26367
Refs: https://github.com/nodejs/node/issues/23259
Refs: https://darksi.de/12.hashwick-v8-vulnerability/
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Downgrade the 'Using floating patch' message that is emitted
when a local patch is applied to the bundled ICU from a warning
to a notice. There isn't anything the user can or should do so
warning isn't appropriate. Instead of angry yellow use soothing green.
Fixes: https://github.com/nodejs/node/issues/26346
PR-URL: https://github.com/nodejs/node/pull/26349
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
This was added in 16f86d6c57, based on
the assumption that otherwise, the memory behind `ArrayBuffer`
instances could be moved around on the heap while native code
holds references to it.
This does not match what V8 actually does (and also did at the time):
- The option/build variable was about always only about TypedArrays,
not ArrayBuffers. Calls like `new ArrayBuffer(4)` call into C++
regardless of the option value, but calls like `new Uint8Array(4)`
would not call into C++ under V8 defaults.
- When first accessing a heap-allocated TypedArray’s `ArrayBuffer`,
whether that is through the JS `.buffer` getter or the C++
`ArrayBufferView::Buffer()` function, a copy of the contents is
created using the ArrayBuffer allocator and stored as the
(permanent, unmovable) backing store.
As a consequence, the memory returned by `ArrayBuffer::GetContents()`
is not moved around, because it is fixed once the `ArrayBuffer`
object itself first comes into explicit existence in any way.
Removing this build option significantly speeds up creation of typed
arrays from JS:
$ ./node benchmark/compare.js --new ./node --old ./node-master --runs 10 --filter buffer-creation.js buffers | Rscript benchmark/compare.R
confidence improvement accuracy (*) (**) (***)
buffers/buffer-creation.js n=1024 len=10 type='buffer()' *** 593.66 % ±28.64% ±41.10% ±60.36%
buffers/buffer-creation.js n=1024 len=10 type='fast-alloc-fill' *** 675.42 % ±90.67% ±130.24% ±191.54%
buffers/buffer-creation.js n=1024 len=10 type='fast-alloc' *** 663.55 % ±58.41% ±83.87% ±123.29%
buffers/buffer-creation.js n=1024 len=10 type='fast-allocUnsafe' 3.10 % ±9.63% ±13.22% ±18.07%
buffers/buffer-creation.js n=1024 len=10 type='slow-allocUnsafe' 4.67 % ±5.55% ±7.77% ±10.97%
buffers/buffer-creation.js n=1024 len=10 type='slow' -2.48 % ±4.47% ±6.12% ±8.34%
buffers/buffer-creation.js n=1024 len=1024 type='buffer()' -1.91 % ±4.71% ±6.45% ±8.79%
buffers/buffer-creation.js n=1024 len=1024 type='fast-alloc-fill' -1.34 % ±7.53% ±10.33% ±14.10%
buffers/buffer-creation.js n=1024 len=1024 type='fast-alloc' 0.52 % ±5.00% ±6.87% ±9.40%
buffers/buffer-creation.js n=1024 len=1024 type='fast-allocUnsafe' 0.39 % ±5.65% ±7.78% ±10.67%
buffers/buffer-creation.js n=1024 len=1024 type='slow-allocUnsafe' -0.13 % ±5.68% ±7.83% ±10.77%
buffers/buffer-creation.js n=1024 len=1024 type='slow' -5.07 % ±7.15% ±9.80% ±13.35%
buffers/buffer-creation.js n=1024 len=2048 type='buffer()' 0.57 % ±2.70% ±3.74% ±5.16%
buffers/buffer-creation.js n=1024 len=2048 type='fast-alloc-fill' -1.60 % ±4.96% ±6.79% ±9.25%
buffers/buffer-creation.js n=1024 len=2048 type='fast-alloc' 1.29 % ±3.79% ±5.20% ±7.09%
buffers/buffer-creation.js n=1024 len=2048 type='fast-allocUnsafe' 2.73 % ±8.79% ±12.05% ±16.41%
buffers/buffer-creation.js n=1024 len=2048 type='slow-allocUnsafe' -0.99 % ±6.27% ±8.65% ±11.91%
buffers/buffer-creation.js n=1024 len=2048 type='slow' -5.98 % ±6.24% ±8.71% ±12.20%
buffers/buffer-creation.js n=1024 len=4096 type='buffer()' -1.75 % ±3.48% ±4.78% ±6.56%
buffers/buffer-creation.js n=1024 len=4096 type='fast-alloc-fill' -3.18 % ±3.97% ±5.45% ±7.45%
buffers/buffer-creation.js n=1024 len=4096 type='fast-alloc' 2.05 % ±4.05% ±5.58% ±7.65%
buffers/buffer-creation.js n=1024 len=4096 type='fast-allocUnsafe' 1.44 % ±5.51% ±7.63% ±10.57%
buffers/buffer-creation.js n=1024 len=4096 type='slow-allocUnsafe' * -4.77 % ±4.30% ±5.90% ±8.06%
buffers/buffer-creation.js n=1024 len=4096 type='slow' -3.31 % ±6.38% ±8.86% ±12.34%
buffers/buffer-creation.js n=1024 len=8192 type='buffer()' 0.06 % ±2.70% ±3.77% ±5.31%
buffers/buffer-creation.js n=1024 len=8192 type='fast-alloc-fill' -1.20 % ±3.30% ±4.53% ±6.17%
buffers/buffer-creation.js n=1024 len=8192 type='fast-alloc' -1.46 % ±2.75% ±3.84% ±5.38%
buffers/buffer-creation.js n=1024 len=8192 type='fast-allocUnsafe' 1.27 % ±4.69% ±6.49% ±8.98%
buffers/buffer-creation.js n=1024 len=8192 type='slow-allocUnsafe' -1.68 % ±3.30% ±4.62% ±6.49%
buffers/buffer-creation.js n=1024 len=8192 type='slow' -2.49 % ±3.24% ±4.44% ±6.07%
(Re-running the outlier with 30 runs instead of 10:)
buffers/buffer-creation.js n=1024 len=4096 type='slow-allocUnsafe' 2.06 % ±2.39% ±3.19% ±4.15%
The performance gains effect are undone once native code accesses
the underlying ArrayBuffer, but then again that a) does not happen for
all TypedArrays, and b) it should also make sense to look into using
`ArrayBufferView::CopyContents()` in some places, which is made
specifically to avoid such a performance impact and allows us to
use the benefits of heap-allocated typed arrays.
Refs: 16f86d6c57
Refs: https://github.com/nodejs/node/pull/2893
Refs: 74178a5682 (commitcomment-13250880)
Refs: http://logs.libuv.org/node-dev/2015-09-15
PR-URL: https://github.com/nodejs/node/pull/26301
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Upstream V8 is dropping support for mips/mipsel/mips64/mips64el.
This commit removes the build flags from the configure script
and some loose ends from the documentation.
PR-URL: https://github.com/nodejs/node/pull/26192
Fixes: https://github.com/nodejs/node/issues/26179
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
This patch replaces the following
1. Usage of `filter` with `None` to remove falsy items.
2. Usage of `map` to create lists. (Replaced with List comprehensions).
3. Dictionary's `iteritems` which is removed in Python 3.
PR-URL: https://github.com/nodejs/node/pull/25580
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Make node-report part of core runtime because:
1. When enabled, node-report significantly helps root cause various
types of problems, including support issues sent to the various repos
of the Node.js organization.
2. The requirement of explicitly adding the dependency to node-report
in user applications often represents a blocker to adoption.
Major deviation from the module version of the node-report is that the
report is generated in JSON format, as opposed to human readable text.
No new functionalities have been added, changes that are required for
melding it as a built-in capability has been affected on the module
version of node-report (https://github.com/nodejs/node-report)
Co-authored-by: Bidisha Pyne <bidipyne@in.ibm.com>
Co-authored-by: Howard Hellyer <hhellyer@uk.ibm.com>
Co-authored-by: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Co-authored-by: Julian Alimin <dmastag@yahoo.com>
Co-authored-by: Lakshmi Swetha Gopireddy <lakshmigopireddy@in.ibm.com>
Co-authored-by: Manusaporn Treerungroj <m.treerungroj@gmail.com>
Co-authored-by: Michael Dawson <michael_dawson@ca.ibm.com>
Co-authored-by: Richard Chamberlain <richard_chamberlain@uk.ibm.com>
Co-authored-by: Richard Lau <riclau@uk.ibm.com>
Co-authored-by: Sam Roberts <vieuxtech@gmail.com>
Co-authored-by: Vipin Menon <vipinmv1@in.ibm.com>
PR-URL: https://github.com/nodejs/node/pull/22712
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <Michael_Dawson@ca.ibm.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
This commit introduces a new configuration flag named
--openssl-is-fips which is intended to be used when linking against
an OpenSSL library that is FIPS compatible.
The motivation for this is that Red Hat Enterprise Linux 8 (RHEL8)
comes with OpenSSL 1.1.1 and includes FIPS support, and we would
like to be able to dynamically link against this version and also have
FIPS features enabled in node, like would be done when statically
linking and using the --openssl-fips flag.
The suggestion here is to introduce a new flag:
$ ./configure --help
...
--openssl-is-fips specifies that the shared OpenSSL version is FIPS
compatible
This flag could be used in combination with the shared-openssl flag:
$ ./configure --shared-openssl ---openssl-is-fips
This will enable FIPS support in node and the runtime flags will be
availalbe to enable FIPS (--enable-fips, --force-fips).
PR-URL: https://github.com/nodejs/node/pull/25412
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Currently, when specifying the --openssl-fips flag without any path
, or an empty path, does not generate an error. If a path is specified
then the following error is generated:
ERROR: FIPS is not supported in this version of Node.js
This commit adds a check so that the error is generated even if the
path is empty.
PR-URL: https://github.com/nodejs/node/pull/25391
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Compiler version tuples should be numeric for tuple comparisons
to work.
Also correct check for AIX where the minimum supported GCC is 6.3.0
PR-URL: https://github.com/nodejs/node/pull/24879
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
PR-URL: https://github.com/nodejs/node/pull/24484
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
There is reason to believe the generated assembly isn't working
correctly so let's disable it for now pending further investigation.
PR-URL: https://github.com/nodejs/node/pull/24270
Refs: https://github.com/nodejs/node/issues/23913
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
llhttp is modern, written in human-readable TypeScript, verifiable, and
is very easy to maintain.
See: https://github.com/indutny/llhttp
PR-URL: https://github.com/nodejs/node/pull/24059
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Under the assumption that debugging is more often focused on node core
source. This setting compiles V8 with only partial optimizations,
DCHECKS, and debug symbols, so it is still very much debuggable,
but it is much faster.
It does disable SLOW_DCHECKS, but at the advice of the V8 team, those
are more important for deep V8 debugging.
Override is configurable with `./configure --v8-non-optimized-debug`.
PR-URL: https://github.com/nodejs/node/pull/23704
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Fixes: https://github.com/nodejs/node/issues/19657
PR-URL: https://github.com/nodejs/node/pull/23766
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
* ATM on every ICU version bump we need to update these data. Reading
it from a file makes it independant of `configre.py` changes.
* Update guide.
PR-URL: https://github.com/nodejs/node/pull/23269
Refs: https://github.com/nodejs/node/issues/23245
Reviewed-By: Steven R Loomis <srloomis@us.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
To support Performance Counters on Windows, a number of
global `COUNTER_` methods were added that are undocumented
and really only intended to be used internally by Node.js.
Unfortunately, the perfctr support apparently hasn't even
worked for quite a while and no one has even complained.
This removes the perfctr support and replaces the global
functions with deprecated non-ops for now, with the intent
of removing those outright in the next major release cycle.
PR-URL: https://github.com/nodejs/node/pull/22485
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: João Reis <reis@janeasystems.com>
!Should go with next commit!
* renaming so that IDEs can properly detect this as python
* Add dependency to Makefile
PR-URL: https://github.com/nodejs/node/pull/22450
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
