Age | Commit message (Collapse) | Author |
|
Original commit message:
Optionally use halfsiphash for integer hashing.
Change-Id: Ibd14f7b3fe78635675c76ae864112e3a3a7bc701
Reviewed-on: https://chromium-review.googlesource.com/c/1382463
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58674}
Refs: https://github.com/v8/v8/commit/c736883ed4e3ff92d1fd5a60497cec5311df9a25
|
|
Original commit message 9365d09:
[coverage] Rework continuation counter handling
This changes a few bits about how continuation counters are handled.
It introduces a new mechanism that allows removal of a continuation
range after it has been created. If coverage is enabled, we run a first
post-processing pass on the AST immediately after parsing, which
removes problematic continuation ranges in two situations:
1. nested continuation counters - only the outermost stays alive.
2. trailing continuation counters within a block-like structure are
removed if the containing structure itself has a continuation.
R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org
Bug: v8:8381, v8:8539
Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1339119
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58443}
Refs: v8/v8@9365d09
Original commit message aac2f8c:
[coverage] Filter out singleton ranges that alias full ranges
Block coverage is based on a system of ranges that can either have
both a start and end position, or only a start position (so-called
singleton ranges). When formatting coverage information, singletons
are expanded until the end of the immediate full parent range. E.g.
in:
{0, 10} // Full range.
{5, -1} // Singleton range.
the singleton range is expanded to {5, 10}.
Singletons are produced mostly for continuation counters that track
whether we execute past a specific language construct.
Unfortunately, continuation counters can turn up in spots that confuse
our post-processing. For example:
if (true) { ... block1 ... } else { ... block2 ... }
If block1 produces a continuation counter, it could end up with the
same start position as the else-branch counter. Since we merge
identical blocks, the else-branch could incorrectly end up with an
execution count of one.
We need to avoid merging such cases. A full range should always take
precedence over a singleton range; a singleton range should never
expand to completely fill a full range. An additional post-processing
pass ensures this.
Bug: v8:8237
Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
Reviewed-on: https://chromium-review.googlesource.com/c/1273095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
Refs: v8/v8@aac2f8c
deps: V8: backport 47d34a3
Original commit message:
Revert "[coverage] change block range to avoid ambiguity."
This reverts commit 471fef0469d04d7c487f3a08e81f3d77566a2f50.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
>
> R=<U+200B>verwaest@chromium.org
>
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
Refs: https://github.com/v8/v8/commit/47d34a317e47bad86b68326607cd2e6de3901f3e
PR-URL: https://github.com/nodejs/node/pull/25429
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
|
|
Original commit message:
[turbofan] Fix -0 check for subnormals.
Previously we'd check `x` for -0 by testing `(1.0 / x) == -Infinity`,
but this will yield the wrong results when `x` is a subnormal, i.e.
really close to 0.
In CSA we already perform bit checks to test for -0, so teach TurboFan
to do the same for comparisons to -0 (via `Object.is`). We introduce a
new NumberIsMinusZero simplified operator to handle the case where
SimplifiedLowering already knows that the input is a number.
Bug: chromium:903043, v8:6882
Change-Id: I0cb7c568029b461a92fc183104d5f359b4bfe7f4
Reviewed-on: https://chromium-review.googlesource.com/c/1328802
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57382}
PR-URL: https://github.com/nodejs/node/pull/25269
Refs: https://github.com/v8/v8/commit/56f6a763c27d77afbee997a50baa34996e97ba40
Fixes: https://github.com/nodejs/node/issues/25268
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
|
|
Original commit message:
[CloneObjectIC] clone MutableHeapNumbers only if !FLAG_unbox_double_fields
Change the macros added in bf84766a2cd3e09070adcd6228a3a487c8dc4bbd to
only do the hard work if FLAG_unbox_double_fields is unset (otherwise,
they will attempt to dereference raw float64s, which is bad!)
Also adds a write barrier in CopyPropertyArrayValues for each store if
it's possible that a MutableHeapNumber is cloned.
BUG=chromium:901301, chromium:902965, chromium:903070, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org, ishell@chromium.org
Change-Id: I224d3c4e7b0a887684bff68985b4d97021ba4cfb
Reviewed-on: https://chromium-review.googlesource.com/c/1323911
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57368}
PR-URL: https://github.com/nodejs/node/pull/25101
Refs: https://github.com/v8/v8/commit/3e010af274088493f3485d7a16dec4e31550e876
Fixes: https://github.com/nodejs/node/issues/25089
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
|
|
Original commit message:
[CloneObjectIC] clone MutableHeapNumbers instead of referencing them
Adds a helper macro "CloneIfMutablePrimitive", which tests if the
operand is a MutableHeapNumber, and if so, clones it, otherwise
returning the original value.
Also modifies the signature of "CopyPropertyArrayValues" to take a
"DestroySource" enum, indicating whether or not the resulting object is
supplanting the source object or not, and removes all default
parameters from that macro (which were not used anyways).
This corrects the issue reported in chromium:901301, where
StaNamedOwnProperty was replacing the value of a MutableHeapNumber
referenced by both the cloned object and the source object.
BUG=chromium:901301, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org
Change-Id: I43df1ddc84dfa4840e680b6affeba452ce0b6629
Reviewed-on: https://chromium-review.googlesource.com/c/1318096
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57304}
PR-URL: https://github.com/nodejs/node/pull/25101
Refs: https://github.com/v8/v8/commit/bf84766a2cd3e09070adcd6228a3a487c8dc4bbd
Fixes: https://github.com/nodejs/node/issues/25089
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
|
|
PR-URL: https://github.com/nodejs/node/pull/25101
Refs: https://github.com/v8/v8/compare/7.1.302.28...7.1.302.33
Fixes: https://github.com/nodejs/node/issues/25089
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
|
|
Original commit message:
Fix collection iterator preview with deleted entries
We used to assume that we know the remaining entries returned by the
iterator based on the current index. However, that is not accurate,
since entries skipped by the current index could be deleted.
In the new approach, we allocate conservatively and shrink the result.
R=neis@chromium.org
Bug: v8:8433
Change-Id: I38a3004dc3af292daabb454bb76f38d65ef437e8
Reviewed-on: https://chromium-review.googlesource.com/c/1325966
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57360}
Refs: https://github.com/v8/v8/commit/88f8fe19a863c6392bd296faf86c06eff2a41bc1
PR-URL: https://github.com/nodejs/node/pull/24514
Refs: https://github.com/nodejs/node/issues/24053
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
|
|
Original commit message:
[profiler] introduce API to enable detailed source positions
This allows Node.js to enable detailed source positions for optimized code
early on, without having to pass a flag string.
R=petermarshall@chromium.org
Change-Id: Ie74ea41f600cf6e31acbe802116df4976ccf1c75
Reviewed-on: https://chromium-review.googlesource.com/c/1319757
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57380}
Refs: https://github.com/v8/v8/commit/073073b4f12b683fc0406cd15b3cb284633fe18e
PR-URL: https://github.com/nodejs/node/pull/24515
Refs: https://github.com/nodejs/node/pull/24274
Refs: https://github.com/nodejs/node/pull/24394
Refs: https://github.com/nodejs/node/issues/24393
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Peter Marshall <petermarshall@chromium.org>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
Original commit message:
[heap-profiler] Fix a use-after-free when snapshots are deleted
If a caller starts the sampling heap profiler and takes a snapshot,
and then deletes the snapshot before the sampling has completed, a
use-after-free will occur on the StringsStorage pointer.
The same issue applies for StartTrackingHeapObjects which shares the
same StringsStorage object.
Bug: v8:8373
Change-Id: I5d69d60d3f9465f9dd3b3bef107c204e0fda0643
Reviewed-on: https://chromium-review.googlesource.com/c/1301477
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57114}
PR-URL: https://github.com/nodejs/node/pull/24272
Refs:
https://github.com/v8/v8/commit/b87d408f65b9ab49a4d199e850d2358995deaeb2
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
|
|
Original commit message:
[api] Allow embedder to construct an Array from Local<Value>*
Currently to obtain a v8::Array out of a C array or a std::vector,
one needs to loop through the elements and call array->Set() multiple
times, and these calls go into v8::Object::Set() which can be slow.
This patch adds a new Array::New overload that converts a
Local<Value>* with known size into a Local<Array>.
Change-Id: I0a768f0e18eec51e78d58be455482ec6425ca188
Reviewed-on: https://chromium-review.googlesource.com/c/1317049
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57261}
Refs: https://github.com/v8/v8/commit/0483e9a9abe77a73632fd85b9c0cd608efa9aa0d
PR-URL: https://github.com/nodejs/node/pull/24125
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
PR-URL: https://github.com/nodejs/node/pull/23423
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
|
|
Original commit message:
Fix collection iterator preview with deleted entries
We used to assume that we know the remaining entries returned by the
iterator based on the current index. However, that is not accurate,
since entries skipped by the current index could be deleted.
In the new approach, we allocate conservatively and shrink the result.
R=neis@chromium.org
Bug: v8:8433
Change-Id: I38a3004dc3af292daabb454bb76f38d65ef437e8
Reviewed-on: https://chromium-review.googlesource.com/c/1325966
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57360}
Refs: https://github.com/v8/v8/commit/88f8fe19a863c6392bd296faf86c06eff2a41bc1
PR-URL: https://github.com/nodejs/node/pull/24514
Refs: https://github.com/nodejs/node/issues/24053
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
|
|
Original commit message:
[profiler] introduce API to enable detailed source positions
This allows Node.js to enable detailed source positions for optimized code
early on, without having to pass a flag string.
R=petermarshall@chromium.org
Change-Id: Ie74ea41f600cf6e31acbe802116df4976ccf1c75
Reviewed-on: https://chromium-review.googlesource.com/c/1319757
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57380}
Refs: https://github.com/v8/v8/commit/073073b4f12b683fc0406cd15b3cb284633fe18e
PR-URL: https://github.com/nodejs/node/pull/24515
Refs: https://github.com/nodejs/node/pull/24274
Refs: https://github.com/nodejs/node/pull/24394
Refs: https://github.com/nodejs/node/issues/24393
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Peter Marshall <petermarshall@chromium.org>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
This reverts commit e2a8e3221b2580c44579c738c12d00fb37298f4a.
This reverts commit 715bbb9d04a320b4c1a234e1f9d878c116beb3f4.
PR-URL: https://github.com/nodejs/node/pull/24394
Fixes: https://github.com/nodejs/node/issues/24393
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
|
|
Original commit message:
[profiler] introduce API to enable detailed source positions
This allows Node.js to enable detailed source positions for optimized code
early on, without having to pass a flag string.
R=petermarshall@chromium.org
Change-Id: Ie74ea41f600cf6e31acbe802116df4976ccf1c75
Reviewed-on: https://chromium-review.googlesource.com/c/1319757
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57380}
PR-URL: https://github.com/nodejs/node/pull/24274
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Peter Marshall <petermarshall@chromium.org>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
|
|
Original commit message:
[heap-profiler] Fix a use-after-free when snapshots are deleted
If a caller starts the sampling heap profiler and takes a snapshot,
and then deletes the snapshot before the sampling has completed, a
use-after-free will occur on the StringsStorage pointer.
The same issue applies for StartTrackingHeapObjects which shares the
same StringsStorage object.
Bug: v8:8373
Change-Id: I5d69d60d3f9465f9dd3b3bef107c204e0fda0643
Reviewed-on: https://chromium-review.googlesource.com/c/1301477
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57114}
PR-URL: https://github.com/nodejs/node/pull/24272
Refs:
https://github.com/v8/v8/commit/b87d408f65b9ab49a4d199e850d2358995deaeb2
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
|
|
Refs: https://github.com/v8/v8/compare/7.0.276.36...7.0.276.38
PR-URL: https://github.com/nodejs/node/pull/24271
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
|
|
Refs: https://github.com/v8/v8/compare/7.0.276.35...7.0.276.36
PR-URL: https://github.com/nodejs/node/pull/24109
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
Original commit message:
[api] Allow embedder to construct an Array from Local<Value>*
Currently to obtain a v8::Array out of a C array or a std::vector,
one needs to loop through the elements and call array->Set() multiple
times, and these calls go into v8::Object::Set() which can be slow.
This patch adds a new Array::New overload that converts a
Local<Value>* with known size into a Local<Array>.
Change-Id: I0a768f0e18eec51e78d58be455482ec6425ca188
Reviewed-on: https://chromium-review.googlesource.com/c/1317049
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57261}
Refs: https://github.com/v8/v8/commit/0483e9a9abe77a73632fd85b9c0cd608efa9aa0d
PR-URL: https://github.com/nodejs/node/pull/24125
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
Refs: https://github.com/v8/v8/compare/7.0.276.32...7.0.276.35
PR-URL: https://github.com/nodejs/node/pull/24056
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
Original commit message:
undef min,max macros on windows
This blocks building with official clang-cl and Windows SDK
Refs: https://github.com/nodejs/node/issues/19630
Change-Id: I41fdf934f486c660df7a9e0dd284f6eb3c294dd4
Reviewed-on: https://chromium-review.googlesource.com/c/1297479
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57053}
PR-URL: https://github.com/nodejs/node/pull/23985
Refs: https://github.com/v8/v8/commit/dc704497ee84245931533c3575dd250d4b498300
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
|
|
Refs: https://github.com/v8/v8/compare/7.0.276.28...7.0.276.32
PR-URL: https://github.com/nodejs/node/pull/23851
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
This was introduced in 48d1335bbc100. Previously, values such as
`undefined` would not be coerced properly because `NumberValue()`
returns `NaN` for them.
Refs: https://github.com/nodejs/node/pull/23158
PR-URL: https://github.com/nodejs/node/pull/23898
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
|
|
Refs: https://github.com/v8/v8/compare/7.0.276.25...7.0.276.28
PR-URL: https://github.com/nodejs/node/pull/23424
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
|
|
Original commit message:
[api] Remove deprecated wasm methods
These methods were deprecated in 7.0, now we can remove them.
R=adamk@chromium.org
Bug: v8:7868
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I60badb378a055152bdd27aed67d11ddf74fce174
Reviewed-on: https://chromium-review.googlesource.com/1209283
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55695}
Refs: https://github.com/v8/v8/commit/b0af30948505b68c843b538e109ab378d3750e37
PR-URL: https://github.com/nodejs/node/pull/23415
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
|
|
PR-URL: https://github.com/nodejs/node/pull/23290
Refs: https://github.com/v8/v8/compare/7.0.276.24...7.0.276.25
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
|
|
This serves as mitigation for the so-called HashWick vulnerability.
Original commit messages:
commit 3833fef57368c53c6170559ffa524c8c69f16ee5
Author: Yang Guo <yangguo@chromium.org>
Date: Thu Sep 20 11:43:13 2018
Refactor integer hashing function names
We now clearly differentiate between:
- unseeded hash for 32-bit integers
- unseeded hash for 64-bit integers
- seeded hash for 32-bit integers
- seeded hash for strings
R=bmeurer@chromium.org
Bug: chromium:680662
Change-Id: I7459958c4158ee3501c962943dff8f33258bb5ce
Reviewed-on: https://chromium-review.googlesource.com/1235973
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56068}
commit 95a979e02d7154e45b293261a6998c99d71fc238
Author: Yang Guo <yangguo@chromium.org>
Date: Thu Sep 20 14:34:48 2018
Call into C++ to compute seeded integer hash
R=bmeurer@chromium.org
Bug: chromium:680662
Change-Id: I8dace89d576dfcc5833fd539ce698a9ade1cb5a0
Reviewed-on: https://chromium-review.googlesource.com/1235928
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56091}
commit 2c2af0022d5feb9e525a00a76cb15db9f3e38dba
Author: Yang Guo <yangguo@chromium.org>
Date: Thu Sep 27 16:37:57 2018
Use 64-bit for seeded integer hashes
R=petermarshall@chromium.org
Bug: chromium:680662
Change-Id: If48d1043dbe1e1bb695ec890c23e103a6cacf2d4
Reviewed-on: https://chromium-review.googlesource.com/1244220
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56271}
Refs: https://github.com/nodejs/node/issues/23259
PR-URL: https://github.com/nodejs/node/pull/23264
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
|
|
Add back a number deprecated APIs, using shims that
should work well enough at least for the duration of Node 11
and do not come with significant maintenance overhead.
Refs: https://github.com/nodejs/node/issues/23122
PR-URL: https://github.com/nodejs/node/pull/23158
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
|
|
Reverting this enables us to provide slower, but longer-lasting
replacements for the deprecated APIs.
Original commit message:
Put back deleted V8_DEPRECATE_SOON methods
This partially reverts
https://chromium-review.googlesource.com/c/v8/v8/+/1177861,
which deleted many V8_DEPRECATE_SOON methods rather than moving them to
V8_DEPRECATED first. This puts them back and marks them V8_DEPRECATED.
Note V8_DEPRECATED that were deleted in the same CL stay deleted.
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
Bug: v8:7786, v8:8240
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I00330036d957f98dab403465b25e30d8382aac22
Reviewed-on: https://chromium-review.googlesource.com/1251422
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/branch-heads/7.0@{#49}
Cr-Branched-From: 6e2adae6f7f8e891cfd01f3280482b20590427a6-refs/heads/7.0.276@{#1}
Cr-Branched-From: bc08a8624cbbea7a2d30071472bc73ad9544eadf-refs/heads/master@{#55424}
Refs: https://github.com/v8/v8/commit/9136dd8088a95484b059a0301b25235510fc2882
Refs: https://github.com/nodejs/node/issues/23122
PR-URL: https://github.com/nodejs/node/pull/23158
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
|
|
Refs: https://github.com/v8/v8/compare/7.0.276.22...7.0.276.24
PR-URL: https://github.com/nodejs/node/pull/23158
Refs: https://github.com/nodejs/node/issues/23122
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
|
|
Refs: https://github.com/v8/v8/compare/7.0.276.20...7.0.276.22
PR-URL: https://github.com/nodejs/node/pull/23160
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
|
|
Original commit message:
[tracing] do not add traces when disabled
https://github.com/nodejs/node/issues/21038
Change-Id: Ic4c9f403b5e54a97d3170b2311dd5aab8c8357c8
Reviewed-on: https://chromium-review.googlesource.com/1217726
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55809}
Refs: https://github.com/v8/v8/commit/2363cdfefeb643285cbe8593b7c17d80e5d06cd9
PR-URL: https://github.com/nodejs/node/pull/22754
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
|
|
PR-URL: https://github.com/nodejs/node/pull/22754
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
|
|
PR-URL: https://github.com/nodejs/node/pull/22898
Refs: https://github.com/v8/v8/compare/6.9.427.22...6.9.427.23
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
|
|
Refs: https://github.com/nodejs/node/issues/22775
PR-URL: https://github.com/nodejs/node/pull/22890
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
|
|
Original commit message:
```
[inspector] added V8InspectorClient::resourceNameToUrl
Some clients (see Node.js) use platform path as ScriptOrigin.
Reporting platform path in protocol makes using protocol much harder.
This CL introduced V8InspectorClient::resourceNameToUrl method that
is called for any reported using protocol url.
V8Inspector uses url internally as well so protocol client may generate
pattern for blackboxing with file urls only and does not need to build
complicated regexp that covers files urls and platform paths on
different platforms.
R=lushnikov@chromium.org
TBR=yangguo@chromium.org
Bug: none
Change-Id: Iff302e7441df922fa5d689fe510f5a9bfd470b9b
Reviewed-on: https://chromium-review.googlesource.com/1164624
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55029}
```
Refs: https://github.com/v8/v8/commit/dbfcc48
PR-URL: https://github.com/nodejs/node/pull/22251
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
|
|
Original commit message:
[tracing] do not add traces when disabled
https://github.com/nodejs/node/issues/21038
Change-Id: Ic4c9f403b5e54a97d3170b2311dd5aab8c8357c8
Reviewed-on: https://chromium-review.googlesource.com/1217726
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55809}
Refs: https://github.com/v8/v8/commit/2363cdfefeb643285cbe8593b7c17d80e5d06cd9
PR-URL: https://github.com/nodejs/node/pull/22812
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
|
|
[cpu-profiler] Add flag to always generate accurate line info.
https://chromium.googlesource.com/v8/v8/+/
56baf56790de439b3f69e887e94beb3b301ed77c
[cpu-profiler] Turn on detailed line info for optimized code
https://chromium.googlesource.com/v8/v8/+/
84894ce6d2af7feb9e1f5574409355120887326c
[cpu-profiler] Separate the flags for generating extra line information
https://chromium.googlesource.com/v8/v8/+/
30ff6719db441cc7ef220d449970cc169067e256
PR-URL: https://github.com/nodejs/node/pull/22688
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
|
|
Original commit message:
[debug] Fully implement Debug::ArchiveDebug and Debug::RestoreDebug.
I have a project that embeds V8 and uses a single `Isolate` from multiple
threads. The program runs just fine, but sometimes the inspector doesn't
stop on the correct line after stepping over a statement that switches
threads behind the scenes, even though the original thread is restored by
the time the next statement is executed.
After some digging, I discovered that the `Debug::ArchiveDebug` and
`Debug::RestoreDebug` methods, which should be responsible for
saving/restoring this `ThreadLocal` information when switching threads,
currently don't do anything.
This commit implements those methods using MemCopy, in the style of other
Archive/Restore methods in the V8 codebase.
Related: https://groups.google.com/forum/#!topic/v8-users/_Qf2rwljRk8
Note: I believe my employer, Meteor Development Group, has previously
signed the CLA using the group email address google-contrib@meteor.com.
R=yangguo@chromium.org,jgruber@chromium.org
CC=info@bnoordhuis.nl
Bug: v8:7230
Change-Id: Id517c873eb81cd53f7216c7efd441b956cf7f943
Reviewed-on: https://chromium-review.googlesource.com/833260
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54902}
Refs: https://github.com/v8/v8/commit/a8f6869177685cfb9c199c454a86f4698c260515
PR-URL: https://github.com/nodejs/node/pull/21983
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
|
Original commit message:
[tracing] allow dynamic control of tracing
If the trace_buffer_ was null, we were returning a pointer to a static
flag back that permanently disabled that particular trace point.
This implied an assumption that tracing will be statically enabled at
process startup, and once it is disabled, it will never be enabled
again. On Node.js side we want to dynamically enable/disable tracing as per
programmer intent.
Change-Id: Ic7a7839b8450ab5c356d85e8e0826f42824907f4
Reviewed-on: https://chromium-review.googlesource.com/1161518
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#54903}
Refs: https://github.com/v8/v8/commit/bf5ea8138c0726613c9d722a3ccb552a8f477992
PR-URL: https://github.com/nodejs/node/pull/21983
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
|
Original commit message:
[cpu-profiler] Use instruction start as the key for the CodeMap
Previously we used the start address of the AbstractCode object. This
doesn't make sense for off-heap builtins, where the code isn't contained
in the object itself. It also hides other potential problems - sometimes
the sample.pc is inside the AbstractCode object header - this is
never valid.
There were a few changes necessary to make this happen:
- Change the interface of CodeMoveEvent. Now 'to' and 'from' are both
AbstractCode objects, which is nice because many users were taking
'to' and adding the header offset to it to try and find the
instruction start address. This isn't valid for off-heap builtins.
- Fix a bug in CodeMap::MoveCode where we didn't update the CodeEntry
object to reflect the new instruction_start.
- Rename the 'start' field in all of the CodeEventRecord sub-classes
to make it clear that this is the address of the first instruction.
- Fix the confusion in RecordTickSample between 'tos' and 'pc' which
caused pc_offset to be calculated incorrectly.
Bug: v8:7983
Change-Id: I3e9dddf74e4b2e96a5f031d216ef7008d6f184d1
Reviewed-on: https://chromium-review.googlesource.com/1148457
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54749}
Refs: https://github.com/v8/v8/commit/ba752ea4c50713dff1e94f45a79db3ba968a8d66
PR-URL: https://github.com/nodejs/node/pull/21983
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
|
Original commit message:
[api][runtime] Support all-in ctors of {Named,Indexed}PropertyHandlerConfiguration
- Explicitly allows construction of
{Named,Indexed}PropertyHandlerConfiguration with all the members filled.
Bug: v8:7612
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I426ea33846b5dbf2b3482c722c963a6e4b0abded
Reviewed-on: https://chromium-review.googlesource.com/1163882
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55142}
PR-URL: https://github.com/nodejs/node/pull/22390
Fixes: https://github.com/nodejs/node/issues/17480
Fixes: https://github.com/nodejs/node/issues/17481
Refs: https://github.com/v8/v8/commit/e1a76995ef311eb3ca66e12ef1941ed596034d59
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
|
|
Original commit message:
[api][keys] Allow skipping indices for Proxies with GetPropertyNames
Bug: v8:7942
Change-Id: I7b3740b04cbcaa56dc809150900ab8d821b054ce
Reviewed-on: https://chromium-review.googlesource.com/1156544
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54821}
Refs: https://github.com/v8/v8/commit/c608122b85238397a43910246f5ff218eb43fb24
PR-URL: https://github.com/nodejs/node/pull/21983
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
|
Original commit message:
Reland "[builtins] Add %IsTraceCategoryEnabled and %Trace builtins"
This is a reland of 8d4572a22b5d2fa0547195bcc40baa18b7565386
Original change's description:
> [builtins] Add %IsTraceCategoryEnabled and %Trace builtins
>
> Adds the builtin Trace and IsTraceCategoryEnabled functions
> exposed via extra bindings. These are intended to use by
> embedders to allow basic trace event support from JavaScript.
>
> ```js
> isTraceCategoryEnabled('v8.some-category')
>
> trace('e'.charCodeAt(0), 'v8.some-category',
> 'Foo', 0, { abc: 'xyz'})
> ```
>
> Bug: v8:7851
> Change-Id: I7bfb9bb059efdf87d92a56a0aae326650730c250
> Reviewed-on: https://chromium-review.googlesource.com/1103294
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Fadi Meawad <fmeawad@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54121}
TBR=cbruni@chromium.org
Bug: v8:7851
Change-Id: Id063754b2834b3b6a2b2654e76e8637bcd6aa5f8
Reviewed-on: https://chromium-review.googlesource.com/1137071
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54532}
Refs: https://github.com/v8/v8/commit/0dd33901a16c7c64290b7e7ddf13945b773c5d79
PR-URL: https://github.com/nodejs/node/pull/21983
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
|
PR-URL: https://github.com/nodejs/node/pull/21983
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
|
PR-URL: https://github.com/nodejs/node/pull/22682
Refs: https://github.com/v8/v8/compare/6.8.275.30...6.8.275.32
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
|
|
[cpu-profiler] Add flag to always generate accurate line info.
https://chromium.googlesource.com/v8/v8/+/
56baf56790de439b3f69e887e94beb3b301ed77c
[cpu-profiler] Turn on detailed line info for optimized code
https://chromium.googlesource.com/v8/v8/+/
84894ce6d2af7feb9e1f5574409355120887326c
[cpu-profiler] Separate the flags for generating extra line information
https://chromium.googlesource.com/v8/v8/+/
30ff6719db441cc7ef220d449970cc169067e256
PR-URL: https://github.com/nodejs/node/pull/22688
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
|
|
Refs: https://github.com/v8/v8/commit/22116dd6c884c026225e56dd8e442a660193e729
Original commit message:
[snapshot] fix resetting function code.
Unconditionally setting the JSFunction code to that of the SFI
may skip initializing the feedback vector.
R=leszeks@chromium.org
Bug: v8:7857
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I65d4bf32493be4cade2eaf3d665d44f93e80f809
Reviewed-on: https://chromium-review.googlesource.com/1107618
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53881}
PR-URL: https://github.com/nodejs/node/pull/21992
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
|
|
Original commit message:
[debug] Fully implement Debug::ArchiveDebug and Debug::RestoreDebug.
I have a project that embeds V8 and uses a single `Isolate` from multiple
threads. The program runs just fine, but sometimes the inspector doesn't
stop on the correct line after stepping over a statement that switches
threads behind the scenes, even though the original thread is restored by
the time the next statement is executed.
After some digging, I discovered that the `Debug::ArchiveDebug` and
`Debug::RestoreDebug` methods, which should be responsible for
saving/restoring this `ThreadLocal` information when switching threads,
currently don't do anything.
This commit implements those methods using MemCopy, in the style of other
Archive/Restore methods in the V8 codebase.
Related: https://groups.google.com/forum/#!topic/v8-users/_Qf2rwljRk8
R=yangguo@chromium.org,jgruber@chromium.org
CC=info@bnoordhuis.nl
Bug: v8:7230
Change-Id: Id517c873eb81cd53f7216c7efd441b956cf7f943
Reviewed-on: https://chromium-review.googlesource.com/833260
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54902}
Refs: https://github.com/v8/v8/commit/a8f6869177685cfb9c199c454a86f4698c260515
Fix build errors by matching older V8 APIs used by Node.
It looks like
SetDebugDelegate(debug::DebugDelegate* delegate, bool pass_ownership)
was simplified to just
SetDebugDelegate(debug::DebugDelegate* delegate)
in https://github.com/v8/v8/commit/37dcd837dbafa7f1175be5f01f0def013437c7e7,
but the extra `pass_ownership` parameter is still there in the current
version of `node/deps/v8`. I should be able to fix those tests by passing
`false` for `pass_ownership`.
Also, the `DebugDelegate::BreakProgramRequested` method lost a parameter
in https://github.com/v8/v8/commit/e404670696b4c49d7f8adcdb075b98acab9967dd,
but it's not a parameter I was using in my test, so there shouldn't be any
harm in adding the `exec_state` parameter back to `BreakProgramRequested`
(and continuing to ignore it).
Skip restoring debug state unless thread previously in DebugScope.
A simpler version of the changes I proposed upstream in this V8 change
request: https://chromium-review.googlesource.com/c/v8/v8/+/1168449
In this version, Debug::RestoreDebug never attempts to enter a new
DebugScope, but merely reuses the previous one, if we're returning to a
thread that was previously in a DebugScope. If the thread was not
previously in a DebugScope, I believe it does not need to have any
debugging state restored with ClearOneShot and PrepareStep.
The tests from https://chromium-review.googlesource.com/c/v8/v8/+/833260
still pass, and the failing V8-CI tests are now passing locally for me.
PR-URL: https://github.com/nodejs/node/pull/22122
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
|
|
Original commit message:
[tracing] allow dynamic control of tracing
If the trace_buffer_ was null, we were returning a pointer to a static
flag back that permanently disabled that particular trace point.
This implied an assumption that tracing will be statically enabled at
process startup, and once it is disabled, it will never be enabled
again. On Node.js side we want to dynamically enable/disable tracing as per
programmer intent.
Change-Id: Ic7a7839b8450ab5c356d85e8e0826f42824907f4
Reviewed-on: https://chromium-review.googlesource.com/1161518
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#54903}
Refs: https://github.com/v8/v8/commit/bf5ea8138c0726613c9d722a3ccb552a8f477992
PR-URL: https://github.com/nodejs/node/pull/22114
Reviewed-By: James M Snell <jasnell@gmail.com>
|