Original commit message:
[api] Add Context::GetMicrotaskQueue method
Add a method that returns the microtask queue that is being used
by the `v8::Context`.
This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:
1. Making sure that “nested” `Context`s use the correct microtask
queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.
Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.
As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.
Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: 2579914
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}
Refs: 4bf051d536
PR-URL: https://github.com/nodejs/node/pull/36482
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Adds methods for fetching stack trace information about
enclosing function.
Refs #36042
Original commit message:
Reland "stack-trace-api: implement getEnclosingLine/Column"
This reverts commit 5557a63beb5a53c93e9b590eaf2933e21bcb3768.
Reason for revert: Sheriff's mistake, failing test was previously flaking.
Original change's description:
> Revert "stack-trace-api: implement getEnclosingLine/Column"
>
> This reverts commit c48ae2d96cbfdc2216706a5e9a79ae1dce5a638b.
>
> Reason for revert: Breaks a profiling test:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/30010
>
> Original change's description:
> > stack-trace-api: implement getEnclosingLine/Column
> >
> > Introduces getEnclosingColumn and getEnclosingLine on CallSite
> > so that the position can be used to lookup the original symbol
> > for function when source maps are used.
> >
> > BUG=v8:11157
> >
> > Change-Id: I06c4c374d172d206579abb170c7b7a2bd3bb159f
> > Reviewed-on: 2547218
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Commit-Queue: Benjamin Coe <bencoe@google.com>
> > Cr-Commit-Position: refs/heads/master@{#71343}
>
> TBR=jkummerow@chromium.org,yangguo@chromium.org,bencoe@google.com
>
> Change-Id: Iab5c250c1c4fbdab86971f4a7e40abc8f87cf79c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:11157
> Reviewed-on: 2555384
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71345}
TBR=bbudge@chromium.org,jkummerow@chromium.org,yangguo@chromium.org,bencoe@google.com
# Not skipping CQ checks because this is a reland.
Bug: v8:11157
Change-Id: I8dba19ceb29a24594469d2cf79626f741dc4cad3
Reviewed-on: 2555499
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71348}
Refs: 86991d0587
PR-URL: https://github.com/nodejs/node/pull/36254
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Original commit message:
[wasm] PostMessage of Memory.buffer should throw
PostMessage of an ArrayBuffer that is not detachable should result
in a DataCloneError.
Bug: chromium:1170176, chromium:961059
Change-Id: Ib89bbc10d2b58918067fd1a90365cad10a0db9ec
Reviewed-on: 2653810
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72415}
Refs: dfcf1e86fa
PR-URL: https://github.com/nodejs/node/pull/37245
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
[api] Add Context::GetMicrotaskQueue method
Add a method that returns the microtask queue that is being used
by the `v8::Context`.
This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:
1. Making sure that “nested” `Context`s use the correct microtask
queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.
Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.
As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.
Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: 2579914
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}
Refs: 4bf051d536
PR-URL: https://github.com/nodejs/node/pull/36482
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Adds methods for fetching stack trace information about
enclosing function.
Refs #36042
Original commit message:
Reland "stack-trace-api: implement getEnclosingLine/Column"
This reverts commit 5557a63beb5a53c93e9b590eaf2933e21bcb3768.
Reason for revert: Sheriff's mistake, failing test was previously flaking.
Original change's description:
> Revert "stack-trace-api: implement getEnclosingLine/Column"
>
> This reverts commit c48ae2d96cbfdc2216706a5e9a79ae1dce5a638b.
>
> Reason for revert: Breaks a profiling test:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/30010
>
> Original change's description:
> > stack-trace-api: implement getEnclosingLine/Column
> >
> > Introduces getEnclosingColumn and getEnclosingLine on CallSite
> > so that the position can be used to lookup the original symbol
> > for function when source maps are used.
> >
> > BUG=v8:11157
> >
> > Change-Id: I06c4c374d172d206579abb170c7b7a2bd3bb159f
> > Reviewed-on: 2547218
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Commit-Queue: Benjamin Coe <bencoe@google.com>
> > Cr-Commit-Position: refs/heads/master@{#71343}
>
> TBR=jkummerow@chromium.org,yangguo@chromium.org,bencoe@google.com
>
> Change-Id: Iab5c250c1c4fbdab86971f4a7e40abc8f87cf79c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:11157
> Reviewed-on: 2555384
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71345}
TBR=bbudge@chromium.org,jkummerow@chromium.org,yangguo@chromium.org,bencoe@google.com
# Not skipping CQ checks because this is a reland.
Bug: v8:11157
Change-Id: I8dba19ceb29a24594469d2cf79626f741dc4cad3
Reviewed-on: 2555499
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71348}
Refs: 86991d0587
PR-URL: https://github.com/nodejs/node/pull/36254
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Original commit message:
[mac] Set MAP_JIT only when necessary
This is a "minimal" change to achieve the required goal: seeing that
there is only one place where we need to indicate that memory should
be reserved with MAP_JIT, we can add a value to the Permissions enum
instead of adding a second, orthogonal parameter.
That way we avoid changing public API functions, which makes this CL
easier to undo once we have platform-independent w^x in Wasm.
Bug: chromium:1117591
Change-Id: I6333d69ab29d5900c689f08dcc892a5f1c1159b8
Reviewed-on: 2435365
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70379}
PR-URL: https://github.com/nodejs/node/pull/35986
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Original commit message:
[platform] Add Permission::kNoAccessWillJitLater enum value
This value is unused for now. This CL is part 1 of a 3-step dance.
Part 2 will be teaching Chrome's Platform implementation to accept
the new value. Part 3 will then actually use it in V8.
Bug: chromium:1117591
Change-Id: Ie3aed20d4cc58f3def3be2a3a03bba4c3a37bf44
Reviewed-on: 2450056
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70335}
PR-URL: https://github.com/nodejs/node/pull/35986
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Original commit message:
[heap-profiler] Fix crash when a snapshot deleted while taking one
Fix a crash/hang that occurred when deleting a snapshot during the
GC that is part of taking another one.
Specifically, when deleting the only other snapshot in such
a situation, the `v8::HeapSnapshot::Delete()` method sees that there
is only one (complete) snapshot at that point, and decides that it is
okay to perform “delete all snapshots” instead of just deleting
the requested one. That resets the internal string lookup table
of the heap profiler, but the new snapshot that is currently in
progress still holds references to the old string lookup table,
leading to a use-after-free segfault or infinite loop.
Fix this by guarding against resetting the string table while
another heap snapshot is being taken, and add a test that would
crash before this fix.
This can be triggered in Node.js by repeatedly calling
`v8.getHeapSnapshot()`, which provides heap snapshots as weakly
held host objects.
Change-Id: If9ac3728bf79114000982f1e7bb05e8034299e3c
Reviewed-on: 2464823
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70445}
Refs: 3176bfd447
PR-URL: https://github.com/nodejs/node/pull/35612
Refs: https://github.com/nodejs/node/issues/35559
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Original commit message:
[mac] Set MAP_JIT only when necessary
This is a "minimal" change to achieve the required goal: seeing that
there is only one place where we need to indicate that memory should
be reserved with MAP_JIT, we can add a value to the Permissions enum
instead of adding a second, orthogonal parameter.
That way we avoid changing public API functions, which makes this CL
easier to undo once we have platform-independent w^x in Wasm.
Bug: chromium:1117591
Change-Id: I6333d69ab29d5900c689f08dcc892a5f1c1159b8
Reviewed-on: 2435365
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70379}
PR-URL: https://github.com/nodejs/node/pull/35986
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Original commit message:
[platform] Add Permission::kNoAccessWillJitLater enum value
This value is unused for now. This CL is part 1 of a 3-step dance.
Part 2 will be teaching Chrome's Platform implementation to accept
the new value. Part 3 will then actually use it in V8.
Bug: chromium:1117591
Change-Id: Ie3aed20d4cc58f3def3be2a3a03bba4c3a37bf44
Reviewed-on: 2450056
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70335}
PR-URL: https://github.com/nodejs/node/pull/35986
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Original commit message:
[wasm][mac] Support w^x codespaces for Apple Silicon
Apple's upcoming arm64 devices will prevent rwx access to memory,
but in turn provide a new per-thread way to switch between write
and execute permissions. This patch puts that system to use for
the WebAssembly subsystem.
The approach relies on CodeSpaceWriteScope objects for now. That
isn't optimal for background threads (which could stay in "write"
mode permanently instead of toggling), but its simplicity makes
it a good first step.
Background:
https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
Bug: chromium:1117591
Change-Id: I3b60f0efd34c0fed924dfc71ee2c7805801c5d42
Reviewed-on: 2378307
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69791}
PR-URL: https://github.com/nodejs/node/pull/35986
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Beth Griggs <bgriggs@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Original commit message:
[heap-profiler] Fix crash when a snapshot deleted while taking one
Fix a crash/hang that occurred when deleting a snapshot during the
GC that is part of taking another one.
Specifically, when deleting the only other snapshot in such
a situation, the `v8::HeapSnapshot::Delete()` method sees that there
is only one (complete) snapshot at that point, and decides that it is
okay to perform “delete all snapshots” instead of just deleting
the requested one. That resets the internal string lookup table
of the heap profiler, but the new snapshot that is currently in
progress still holds references to the old string lookup table,
leading to a use-after-free segfault or infinite loop.
Fix this by guarding against resetting the string table while
another heap snapshot is being taken, and add a test that would
crash before this fix.
This can be triggered in Node.js by repeatedly calling
`v8.getHeapSnapshot()`, which provides heap snapshots as weakly
held host objects.
Change-Id: If9ac3728bf79114000982f1e7bb05e8034299e3c
Reviewed-on: 2464823
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70445}
Refs: 3176bfd447
PR-URL: https://github.com/nodejs/node/pull/35612
Refs: https://github.com/nodejs/node/issues/35559
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Original commit message:
[heap-profiler] Fix crash when a snapshot deleted while taking one
Fix a crash/hang that occurred when deleting a snapshot during the
GC that is part of taking another one.
Specifically, when deleting the only other snapshot in such
a situation, the `v8::HeapSnapshot::Delete()` method sees that there
is only one (complete) snapshot at that point, and decides that it is
okay to perform “delete all snapshots” instead of just deleting
the requested one. That resets the internal string lookup table
of the heap profiler, but the new snapshot that is currently in
progress still holds references to the old string lookup table,
leading to a use-after-free segfault or infinite loop.
Fix this by guarding against resetting the string table while
another heap snapshot is being taken, and add a test that would
crash before this fix.
This can be triggered in Node.js by repeatedly calling
`v8.getHeapSnapshot()`, which provides heap snapshots as weakly
held host objects.
Change-Id: If9ac3728bf79114000982f1e7bb05e8034299e3c
Reviewed-on: 2464823
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70445}
Refs: 3176bfd447
PR-URL: https://github.com/nodejs/node/pull/35612
Refs: https://github.com/nodejs/node/issues/35559
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Original commit message:
[coverage] IncBlockCounter should not be side-effect
Incrementing coverage counter was triggering EvalError for
evaluateOnCallFrame when throwOnSideEffect is true.
R=jgruber@chromium.org, sigurds@chromium.org, yangguo@chromium.org
Bug: v8:10856
Change-Id: I0552e19a3a14ff61a9cb626494fb4a21979d535e
Reviewed-on: 2384011
Commit-Queue: Benjamin Coe <bencoe@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69628}
Refs: 6be2f6e26e
PR-URL: https://github.com/nodejs/node/pull/35055
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Original commit message:
[api] Fix empty Maybe crash in GetRealNamedPropertyAttributes
`Object::GetRealNamedPropertyAttributes()` can crash if an empty
`Maybe` is returned by `JSReceiver::GetPropertyAttributes()` because
it was not checking for that. Fix that.
Refs: https://github.com/nodejs/node/issues/34606
Change-Id: Ic83f904ba7134786bcd8f786eb2ce98adb4fea1e
Reviewed-on: 2335057
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69258}
Refs: e06ace6b5c
PR-URL: https://github.com/nodejs/node/pull/34673
Fixes: https://github.com/nodejs/node/issues/34606
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[coverage] remove the last continuation range before synthetic return
Rather than only removing the continuation range for the last return
statement prior to a synthetic return statement, remove the
continuation tracking for whatever statement occurs prior to the
synthetic return.
Bug: v8:10628
Change-Id: Ieb8e393479c9811cf1b9756840bbfdbe7f44a1b8
Reviewed-on: 2280585
Commit-Queue: Benjamin Coe <bencoe@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68719}
Refs: 2d5017a0fc
PR-URL: https://github.com/nodejs/node/pull/34272
Refs: https://github.com/bcoe/c8/issues/229
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Original commit message:
Reland "[snapshot] rehash JSMap and JSSet during deserialization"
This is a reland of 8374feed55a5b3010f2e9593560a2d84f9f6725f.
Fixed rehashing of global proxy keys by creating its identity hash
early, before the deserialization of the context snapshot.
Original change's description:
> [snapshot] rehash JSMap and JSSet during deserialization
>
> To rehash JSMap and JSSet, we simply replace the backing store
> with a new one created with the new hash.
>
> Bug: v8:9187
> Change-Id: I90c25b18b33b7bc2b6ffe1b89fe17aa5f978b517
> Reviewed-on: 2143983
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67663}
Bug: v8:9187, v8:10523
Change-Id: I7a0319b1d10ff07644de902fec43e7c2b1dd8da9
Reviewed-on: 2212085
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#67999}
Refs: 22014de001
PR-URL: https://github.com/nodejs/node/pull/33300
Refs: ea0719b8ed
Refs: bb9f0c2b2f
Refs: https://github.com/nodejs/node/issues/17058
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Original commit message:
[coverage] remove the last continuation range before synthetic return
Rather than only removing the continuation range for the last return
statement prior to a synthetic return statement, remove the
continuation tracking for whatever statement occurs prior to the
synthetic return.
Bug: v8:10628
Change-Id: Ieb8e393479c9811cf1b9756840bbfdbe7f44a1b8
Reviewed-on: 2280585
Commit-Queue: Benjamin Coe <bencoe@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68719}
Refs: 2d5017a0fc
PR-URL: https://github.com/nodejs/node/pull/34272
Refs: https://github.com/bcoe/c8/issues/229
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Original commit message:
[API] Fix microtask message reporting
RunSingleMicrotask calls Runtime::ReportMessage, but the implementation
of ReportMessage would unconditionally discard these exceptions. This
CL removes all of the intermediate logic and directly calls
MessageHandler::ReportMessage, restoring the ability of
RunSingleMicrotask to report exceptions that occur in microtasks.
Bug: v8:8326
Change-Id: I493de74383b2ab191d786611fb9eba9d27e7a243
Reviewed-on: 2162121
Commit-Queue: Gus Caplan <me@gus.host>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67630}
Refs: 767e65f945
PR-URL: https://github.com/nodejs/node/pull/33859
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
Skip InterpreterWithNativeStack on jitless mode
As discussed under https://crrev.com/c/1981505,
Test requires an executable CODE_SPACE and is thus incompatible with
jitless mode.
Change-Id: Icddad50a3484f0cfc5fb4abd7175058d50bc06d3
Reviewed-on: 2193911
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67726}
Refs: 4e1bf2bc92
PR-URL: https://github.com/nodejs/node/pull/33702
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Original commit message:
Revert "s390: [arm] Add missing RELATIVE_CODE_TARGET iteration"
This reverts commit 9d3cca1cd3ad7c6653cab1cdf111d356f33f77cd.
Reason for revert: Only the test needs to be skipped on s390. Refer to this: https://crrev.com/c/1981505
Original change's description:
> s390: [arm] Add missing RELATIVE_CODE_TARGET iteration
>
> Port b766299d2c382cc9817e73225bbebe29ce62b9d1
> Port 9592b043eed86db91a441d4bf78b7f0c8c2ce4dd
> Port d915b8d668615a7d6d75cf7a61d3ca5a3d139799
>
> Original Commit Message:
>
> Code object iteration was missing logic for RELATIVE_CODE_TARGET
> reloc entries. Garbage collection could thus miss objects that were
> referenced only as targets of pc-relative calls or jumps.
>
> RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
> at mksnapshot-time.
>
> This exposed another issue in that the interpreter entry trampoline
> copy we generate for profiling *did* contain relative calls in
> runtime-accessible code. This is a problem, since code space on arm is,
> by default, too large to be fully addressable through pc-relative
> calls. This CL thus also disables the related
> FLAG_interpreted_frames_native_stack feature on arm.
>
> objects.
>
> R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
> LOG=N
>
> Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2
> Reviewed-on: 2087693
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
> Cr-Commit-Position: refs/heads/master@{#66644}
TBR=michael_dawson@ca.ibm.com,mlippautz@chromium.org,jyan@ca.ibm.com,jgruber@chromium.org,joransiu@ca.ibm.com,miladfar@ca.ibm.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Id645a9def23d278235ff77f25249d2187e8105ca
Reviewed-on: 2196521
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67751}
Refs: b5939c7589
PR-URL: https://github.com/nodejs/node/pull/33702
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Original commit message:
[turbofan] Fixes for integrating the fast C API
This commit adds a few fixes neccessary for integrating the
fast C API into Blink:
- added default constructor for CFunction
- removed a bogus template specialization allowing void* params
- extended the public Isolate class
Bug: chromium:1052746
Change-Id: I4f2ba84299920e2cc9d66ec1ed59302313db6c0b
Reviewed-on: 2120587
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66986}
Refs: 0d6debcc5f
PR-URL: https://github.com/nodejs/node/pull/33600
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Original commit message:
Reland "[snapshot] rehash JSMap and JSSet during deserialization"
This is a reland of 8374feed55a5b3010f2e9593560a2d84f9f6725f.
Fixed rehashing of global proxy keys by creating its identity hash
early, before the deserialization of the context snapshot.
Original change's description:
> [snapshot] rehash JSMap and JSSet during deserialization
>
> To rehash JSMap and JSSet, we simply replace the backing store
> with a new one created with the new hash.
>
> Bug: v8:9187
> Change-Id: I90c25b18b33b7bc2b6ffe1b89fe17aa5f978b517
> Reviewed-on: 2143983
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67663}
Bug: v8:9187, v8:10523
Change-Id: I7a0319b1d10ff07644de902fec43e7c2b1dd8da9
Reviewed-on: 2212085
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#67999}
Refs: 22014de001
PR-URL: https://github.com/nodejs/node/pull/33300
Refs: ea0719b8ed
Refs: bb9f0c2b2f
Refs: https://github.com/nodejs/node/issues/17058
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Original commit message:
[arraybuffer] Clean up BackingStore even if it pointer to nullptr
For a zero-length BackingStore allocation, it is valid for the
underlying memory to be a null pointer. However, some cleanup
is still necessary, since the BackingStore may hold a reference
to the allocator itself, which needs to be released when destroying
the `BackingStore` instance.
Change-Id: I1f168079d39e4592d2fde31fbe5f705586690e85
Reviewed-on: 2169646
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67420}
Refs: e29c62b748
PR-URL: https://github.com/nodejs/node/pull/32831
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
Fix compilation error with devtoolset-8
We are compiling V8 using devtoolset-8 and it is generating a new
compilation error related to String Truncation:
error: ‘char* strncpy(char*, const char*, size_t)’ output truncated copying between 1 and 15 bytes from a string of length 15 [-Werror=stringop-truncation]
strncpy(buffer, unicode_utf8, i);
Which basically means the null terminating character was not added to
the end of the buffer:
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/
This CL will changes 2 uses of "strncpy" to "memcpy" as strings
are being copied partially and `\n` being added at a later stage.
Change-Id: I3656afb00463d70ddb8700a487a1978b793e1d09
Reviewed-on: 2155038
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67277}
Refs: e1eac1b16c
PR-URL: https://github.com/nodejs/node/pull/32831
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Original commit message:
[arraybuffer] Clean up BackingStore even if it pointer to nullptr
For a zero-length BackingStore allocation, it is valid for the
underlying memory to be a null pointer. However, some cleanup
is still necessary, since the BackingStore may hold a reference
to the allocator itself, which needs to be released when destroying
the `BackingStore` instance.
Change-Id: I1f168079d39e4592d2fde31fbe5f705586690e85
Reviewed-on: 2169646
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67420}
Refs: e29c62b748
PR-URL: https://github.com/nodejs/node/pull/33125
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Original commit message:
Fix compilation error with devtoolset-8
We are compiling V8 using devtoolset-8 and it is generating a new
compilation error related to String Truncation:
error: ‘char* strncpy(char*, const char*, size_t)’ output truncated copying between 1 and 15 bytes from a string of length 15 [-Werror=stringop-truncation]
strncpy(buffer, unicode_utf8, i);
Which basically means the null terminating character was not added to
the end of the buffer:
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/
This CL will changes 2 uses of "strncpy" to "memcpy" as strings
are being copied partially and `\n` being added at a later stage.
Change-Id: I3656afb00463d70ddb8700a487a1978b793e1d09
Reviewed-on: 2155038
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67277}
Refs: e1eac1b16c
PR-URL: https://github.com/nodejs/node/pull/32974
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ujjwal Sharma <ryzokuken@disroot.org>
While landing the upgrade to V8 8.1, something went wrong and git made
unecessary (and incorrect) whitespace changes to test fixtures, which
broke V8 tests. Revert those changes to fix our tests.
PR-URL: https://github.com/nodejs/node/pull/32587
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Original commit message:
Fix scanner-level error reporting for hashbang
When the file begins with a hashbang, the scanner is in a failed state
when SkipHashbang() is called. This is usually not an issue but when
the parser encounters an ILLEGAL token, it will reset the SyntaxError
location because of it.
Bug: v8:10110
Change-Id: I1c7344bf5ad20079cff80130c991f3bff4d7e9a8
Reviewed-on: 1995312
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66038}
Refs: f9257802c1
Fixes: https://github.com/nodejs/node/issues/31284
Signed-off-by: Matheus Marchini <mmarchini@netflix.com>
PR-URL: https://github.com/nodejs/node/pull/32180
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
