- Mar 02, 2019
-
-
Sebastiaan Deckers authored
PR-URL: https://github.com/nodejs/node/pull/26309 Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Rich Trott <rtrott@gmail.com> Reviewed-By:
Matteo Collina <matteo.collina@gmail.com> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Luigi Pinca <luigipinca@gmail.com>
-
Beni von Cheni authored
PR-URL: https://github.com/nodejs/node/pull/26312 Reviewed-By:
Rich Trott <rtrott@gmail.com> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By:
Luigi Pinca <luigipinca@gmail.com>
-
Rich Trott authored
Update babel-eslint to 10.0.1. PR-URL: https://github.com/nodejs/node/pull/26347 Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Shingo Inoue <leko.noor@gmail.com> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de>
-
Ben Noordhuis authored
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>
-
Anna Henningsen authored
Provide `process.execArgv`. If an `execArgv` option is passed to the `Worker` constructor, that option is used as its value; if not, the parent’s `process.execArgv` is inherited (since that also goes for the actual options in that case). PR-URL: https://github.com/nodejs/node/pull/26267 Reviewed-By:
Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
Tobias Nießen authored
PR-URL: https://github.com/nodejs/node/pull/26249 Reviewed-By:
Sam Roberts <vieuxtech@gmail.com> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Rich Trott <rtrott@gmail.com>
-
Rich Trott authored
For eslint-plugin-markdown, we had been using an RC but can now use the most recent stable release of 1.0.0, as it has the bugfix that caused us to start using the RC in the first place. There are a few other updates in this commit too because it was performed by running `update-eslint.sh`. This did not update ESLint itself but did update some dependencies. PR-URL: https://github.com/nodejs/node/pull/26345 Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com>
-
Rich Trott authored
eslint-plugin-markdown is being installed @next to get a bugfix for https://github.com/eslint/eslint-plugin-markdown/issues/69 but that bugfix is in 1.0.0. Go back to installing @latest rather than @next. PR-URL: https://github.com/nodejs/node/pull/26345 Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com>
-
Luigi Pinca authored
PR-URL: https://github.com/nodejs/node/pull/26152 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de>
-
Luigi Pinca authored
PR-URL: https://github.com/nodejs/node/pull/26152 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de>
-
gengjiawen authored
PR-URL: https://github.com/nodejs/node/pull/26204 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
gengjiawen authored
PR-URL: https://github.com/nodejs/node/pull/26242 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de>
-
Thomas authored
Ref: https://github.com/nodejs/node/issues/25987 PR-URL: https://github.com/nodejs/node/pull/26096 Refs: https://github.com/nodejs/node/issues/25987 Reviewed-By:
Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By:
Gabriel Schulhof <gabriel.schulhof@intel.com>
-
Richard Lau authored
Attempt to report the host and port in the case that uv_getnameinfo() fails. PR-URL: https://github.com/nodejs/node/pull/26140 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com>
-
Anna Henningsen authored
Unlike `node::Persistent`, `v8::Global` has move semantics and can be used directly in STL containers. PR-URL: https://github.com/nodejs/node/pull/26254 Reviewed-By:
Gus Caplan <me@gus.host> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By:
Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
Anna Henningsen authored
- Prefer RAII-style management over manual resource management. - Prefer `env->SetImmediate()` over a separate `uv_async_t`. - Perform `ares_destroy()` before possibly tearing down c-ares state. - Verify that the number of active queries is non-negative. - Let pending callbacks know when their underlying `QueryWrap` object has been destroyed. The last item has been a real bug, in that when Workers shut down during currently running DNS queries, they may run into use-after-free situations because: 1. Shutting the `Worker` down leads to the cleanup code deleting the `QueryWrap` objects first; then 2. deleting the `ChannelWrap` object (as it has been created before the `QueryWrap`s), whose destructor runs `ares_destroy()`, which in turn invokes all pending query callbacks with `ARES_ECANCELLED`, 3. which lead to use-after-free, as the callback tried to access the deleted `QueryWrap` object. The added test verifies that this is no longer an issue. PR-URL: https://github.com/nodejs/node/pull/26253 Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
Anna Henningsen authored
Check that small typed arrays, including `Buffer`s (unless allocated by `Buffer.allocUnsafe()`), are indeed heap-allocated. 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>
-
Anna Henningsen authored
Do not create an `ArrayBuffer` if the engine’s settings avoid it and we don’t need it. 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>
-
Anna Henningsen authored
Where appropriate, use a helper that wraps around `ArrayBufferView::Buffer()` or `ArrayBufferView::CopyContents()` rather than `Buffer::Data()`, as that may help to avoid materializing the underlying `ArrayBuffer` when reading small typed arrays from C++. This allows keeping the performance benefits of the faster creation of heap-allocated small typed arrays in many cases. 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>
-
Anna Henningsen authored
This was added in 16f86d6c, 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: https://github.com/nodejs/node/commit/16f86d6c578ff7aec708c7d736558a199d290e9c Refs: https://github.com/nodejs/node/pull/2893 Refs: https://github.com/nodejs/node/commit/74178a5682958d499896e0fa1af6bc0321ec1935#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>
-
Anna Henningsen authored
This was overlooked in c5832453. Refs: https://github.com/nodejs/node/pull/26137 PR-URL: https://github.com/nodejs/node/pull/26295 Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Tobias Nießen <tniessen@tnie.de>
-
Anna Henningsen authored
It’s not obvious why this was a heap allocation in the first place, but it’s unneccessary. Most other `HandleWrap`s also store the libuv handle directly. PR-URL: https://github.com/nodejs/node/pull/26271 Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By:
Gireesh Punathil <gpunathi@in.ibm.com>
-
Anna Henningsen authored
PR-URL: https://github.com/nodejs/node/pull/26271 Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By:
Gireesh Punathil <gpunathi@in.ibm.com>
-
Anna Henningsen authored
PR-URL: https://github.com/nodejs/node/pull/26243 Reviewed-By:
Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By:
Colin Ihrig <cjihrig@gmail.com>
-
cjihrig authored
PR-URL: https://github.com/nodejs/node/pull/26368 Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By:
Luigi Pinca <luigipinca@gmail.com>
-
- Mar 01, 2019
-
-
Avi ד authored
Prevents moving left or right from placing the cursor in between code units comprising a code point. PR-URL: https://github.com/nodejs/node/pull/25723 Fixes: https://github.com/nodejs/node/issues/25693 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de>
-
Ruben Bridgewater authored
This moves a condition inside of a for loop which can only be triggered at the very end of the for loop outside of the loop. That way the for loop itself is much simpler and easier to understand and the code itself is less indented which should increase the readability. It also refactors some `var` to `let` and `const`. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
This moves the `if (len === 1)` case to the top of the function. That way it is possible to reduce the indentation level due to returning early in that case. On top of that the following was done: 1) For clarity refactored for loops which were meant to count up a variable into a while loop. 2) Used template strings instead of string concat. 3) Consolidating nested if statements. 4) Using tenary expressions if applicable when assigning variables to reduce the code overhead. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
Either `end` is `-1` or `startPart` is not `0`. Therefore it's possible to move the conditions in a way that we eliminate a few code branches. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
This refactoring makes sure some code branches will not be hit if they do not have to be reached. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
1) Consolidate nested if statements if possible `if (foo) { if bar () { /* do stuff */ } }`) to reduce indentation depth. 2) Remove obsolete else cases to reduce indentation. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
1) Consolidate format to a single function. 2) Move some code that can only be reached in some code branches that was formerly executed in all cases. 3) Explicitly check for the string length of zero instead of converting the string to a boolean. 4) Consolidate nested if statements if possible e.g., if (foo) { if (bar) { /* do stuff */ } } to reduce indentation depth. 5) Simplify checks by removing extra length checks when comparing two strings. 6) Use object shorthand notation where possible. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
1) Refactor for loops to while loops that were only meant to count up a variable. 2) Refactor some `var` statements to `let` / `const`. 3) Simplify return conditions. 4) Use template strings where possible instead of concat. 5) Use ternary expressions for variable assignments instead of if / else. 6) Use the object shorthand notation for the function declarations. 7) Consolidate if else case where possible. 8) Remove double line breaks. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
1) This uses some ternary expressions instead of if else to assign some variables. 2) Use template strings instead of concat. 3) Use the object shortand notation. 4) Some var to let / const. 5) Removed some double line breaks. 6) Less brackets around statements if not necessary. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
The current caching logic broke by [0] because it used destructuring on the module arguments. Since the exported property is a primitive counting it up or down would not have any effect anymore in the module that required that property. The original implementation would cache all stat calls caused during bootstrap. Afterwards it would clear the cache and lazy require calls during runtime would create a new cascading cache for the then loaded modules and clear the cache again. This behavior is now restored. This is difficult to test without exposing a lot of information and therfore the existing tests have been removed (as they could not detect the issue). With the broken implementation it caused each module compilation to reset the cache and therefore minimizing the effect drastically. [0] https://github.com/nodejs/node/pull/19177 PR-URL: https://github.com/nodejs/node/pull/26266 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
Ruben Bridgewater authored
This simplifies the shebang function significantly. Before, it was optimized for two characters input. Any module actually parsed should however have more characters than just the shebang. The performance stays the same as before. PR-URL: https://github.com/nodejs/node/pull/26266 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
Alexander Sattelmaier authored
PR-URL: https://github.com/nodejs/node/pull/26163 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
Alexander Sattelmaier authored
PR-URL: https://github.com/nodejs/node/pull/26163 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
gengjiawen authored
PR-URL: https://github.com/nodejs/node/pull/26218 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
MaleDong authored
Due to `maledong_private@qq.com` is useless because I cannot log in with the email address (GitHub doesn't support `qq` mail well), and I've successfully changed my email account to `maledong_github@outlook.com` instead. So I removed my old useless email address and keep the new one for the same account 'MaleDong', because there're two 'MaleDong' Accounts and they are both pointing to me. The final solution is that to add my own email account address into the '.mailmap' to let AUTHORS re-generated. PR-URL: https://github.com/nodejs/node/pull/26146 Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
James M Snell <jasnell@gmail.com> Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de>
-