This adds a handle scope to Module::validate in C API
so that the wasm_module_validate can be usable from C.
Without the added handle scope, attempting to call
wasm_module_validate function from C code fails with:
#
# Fatal error in v8::HandleScope::CreateHandle()
# Cannot create a handle without a HandleScope
#
Bug: v8:12941
Change-Id: I2b4d5dccdaed9501f31447158ebf8e7906a1f8f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3692020
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81048}
Change-Id: I88a1bbddc7604fc5e557ae875ca196cf9c46574c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3626453
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Neden Wang <nedenwang@tencent.com>
Cr-Commit-Position: refs/heads/main@{#80390}
This CL includes count value to InvalidCountValue error message to make
it easier to dignoise RangeError of String.prototype.repeat. When
InvalidCountValue error throw, we could not know it's
caused by which count value if count value is not included.
Bug: none
Change-Id: I16e6693da0fc3b181241cb90daca27957f59c77c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593574
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80198}
With this CL, spilled parameters with ref type in a call to wasm
function, will be placed at a consecutive area in the generic
JSToWasmWrapper frame as WasmCallDescriptor expected.
Bug: v8:12722
Change-Id: I8b82f35b712a32b87abf5100ec46ee499a8178bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563445
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79805}
Bidirectional phase switching by shortcuts "n", "b".
Improved selection of nodes when they are splitting or raising to a common ancestor.
Fixed minor inconsistencies in some variable names with the project style.
Added name and email to the AUTHORS file for first-time contribution.
Change-Id: I0c903dbf81c3d1d75503004ce412a81aace06a61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3537008
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79636}
Some edges are self looping because of incorrect `horizontalPos`. This is occuring because of an unexpected scenario caused due to incorrect calculation of `inputApproch` and `outputApproach`. And all of this is occuring because of insufficient distance between two nodes.
An example of the problem is shown in the image: https://imgur.com/aAmnzaK.
Change-Id: I056e1fbcc420ce65a3ae9201e187b22ad3fbaaba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3535791
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79570}
When I was looking at the v8 Promise source, I noticed that some of the links that needed to point to ECMA262 were broken, some were deprecated, some were not legitimate, so I tried to fix them.
Bug: no
Change-Id: I26deeb635d8c293245e7cdb62089f60557547846
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3462029
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79411}
Adding ldflags for aix. This is a todo item noticed
Change-Id: I09dc86a3e956408edb1bfeba6b60bf67843caf4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439339
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79086}
Originally, 'Promise.allSettled.call()' will throw
"Promise.all called on non-object". It should be
"Promise.allSettled called on non-object".
Bug: v8:12122
Change-Id: Ib2c8eba32abec474feece3aaebf0e6c7d09c433a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3459923
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79085}
Commit 84f3877c15 moved IsInRange to
base::IsInRange and updated src/parsing/keywords-gen.h, but did not
update tools/gen-keywords-gen-h.py.
Bug: v8:12507
Change-Id: I914ba73feac3bac6fd5d08d14d17149faf6c5c76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3356200
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78467}
Currently it is not possible to run samples on arm architecture
I faced the issue on Macbook Pro M1
Running sample codes is crucial for getting started with the project
R=tandrii@chromium.org
Bug: None
Change-Id: Ie3ed52e68d1f7193217110d43545971c714202c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251026
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77653}
Implement `LiftoffAssembler::emit_i16x8_sconvert_i32x4` for riscv.
Add tests for rvv integer and floating-point instructions.
Add simulator support for rvv instructions, e.g. `vfmadd`, `vnclip`.
Fixed order of operands for `vfdiv.vv`.
Bug: v8:11976
Change-Id: I0691ac66771468533c5994be1fc8a86b09d3c738
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3225319
Reviewed-by: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77595}
1. Now there is no serializer/deserializer-specific buffer size limit.
2. Update AUTHORS
Ref: https://github.com/nodejs/node/issues/40059
Change-Id: Iad4c6d8f68a91ef21d3c404fb7945949e69ad9e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3170411
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77084}
After building V8 using Clang (./out/x64.release/v8_build_config.json
says that "is_clang" is true), I could reproduce the referenced bug
report locally. Replacing the getMinutes() calls with getUTCMinutes()
calls fixed the test failure.
Signed-off-by: Darshan Sen <raisinten@gmail.com>
Bug: v8:11200
Change-Id: Ia36be481f2c8728380d550ead856ef8e51b1069c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093362
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76367}
Bug: v8:12092
Change-Id: Ibca6082c28cfd5b23680d554b692bc8ab60cb416
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094013
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76300}
Previously V8 was reusing the error fur duplicate declarations, using
the private name for class fields or the class name for class methods
as the redeclared identifier.
class A { constructor(o) { return o } }
class B extends A { #x }
class C extends A { #x() {} }
let D = (0, class extends A { #x() {} });
new B(new B({})) // Identifier '#x' has already been declared
new C(new C({})) // Identifier 'C' has already been declared
new D(new D({})) // Identifier '' has already been declared
This patch changes it to use error messages that better explain what's
happening:
new B(new B({})) // Cannot initialize #x twice on the same object
new C(new C({})) // Cannot initialize private methods of
// class C twice on the same object
new D(new D({})) // Cannot initialize private methods of
// class anonymous twice on the same object
I initially tried to use the same message for both fields and methods,
but the problem with that is that when initializing fields we only
have access to the field name, while when initializing methods we only
have access to the class name (using the "private brand" symbol).
However, almost all the error messages are different for private fields
and for methods so this shouldn't be a problem.
Bug: v8:12042
Change-Id: Iaa50c16e4fa5c0646ad9ef2aa7e65bb649b3fce2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3078362
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Joyee Cheung <joyee@igalia.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76279}
This allows for marking promises as silent. Setting this flag prevents
the debugger from pausing when the promise rejects.
Bug: chromium:1132506
Change-Id: I260e52faa45ebedd9e8d84e092bd0260e828a902
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001354
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75595}
The change is made since for switch statements with lots of cases,
where each case is a constant integer, the emitted bytecode is still
a series of jumps, when we can instead use a jump table.
If there are 6 or more cases (similar to GCC) of Smi literals, and
if the max Smi case minus the min Smi case is not more than 3 times
the number of cases, we use a jump table up front to handle Smi's,
and then use traditional if-else logic for the rest of the cases.
We then use the jump table in interpreter/bytecode-jump-table to
do the optimization.
This tries to go off issue 9738 in v8's issue tracker. It is not
exactly the same, since that recommends doing the work at JIT-time,
but has similar ideas. It also partially goes off issue 10764.
Bug: v8:9738
Change-Id: Ic805682ee3abf9ce464bb733b427fa0c83a6e10c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904926
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75323}
LiftoffRegister::gp() and LiftoffRegister::fp() are constexpr.
Therefore, VRegister::from_code() needs to be constexpr as well.
Bug: chromium:819294
Change-Id: I5a75d6ae0dc79fce0a42a45c5f7928aa61ac5520
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922887
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Stephan Hartmann <stha09@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#74932}
Update the way urllib is imported. As of Python 3, the old `urllib2`
was split into several smaller modules under `urllib`.
This commit unifies the resulting imported names across Python 2 and
Python 3, for forward/backward compatibility.
Bug: v8:9871
Change-Id: I81310ea83536269ae0cdf1406fd69285928c9357
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848488
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74209}
This is a reland of d5457f5fb7
after a speculative revert.
Additionally it fixes an issue with throwing promise hooks.
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Bug: chromium:1197475
Change-Id: I73a71e97d9c3dff89a2b092c3fe4adff81ede8ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2823917
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74071}
This CL adds features to pack/unpack map words.
Currently V8 cannot store extra metadata in object headers -- because V8
objects do not have a proper header, but only a map pointer at the start
of the object. To store per-object metadata like marking data, a side
table is required as the per-object metadata storage.
This CL enables V8 to use higher unused bits in a 64-bit map word as
per-object metadata storage. Map pointer stores come with an extra step
to encode the metadata into the pointer (we call it "map packing").
Map pointer loads will also remove the metadata bits as well (we call it
"map packing").
Since the map word is no longer a valid pointer after packing, we also
change the tag of the packed map word to make it looks like a Smi. This
helps various GC and barrier code to correctly skip them instead of
blindly dereferencing this invalid pointer.
A ninja flag `v8_enable_map_packing` is provided to turn this
map-packing feature on and off. It is disabled by default.
* Only works on x64 platform, with `v8_enable_pointer_compression`
set to `false`
Bug: v8:11624
Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73915}
Defence in depth patch to prevent JavaScript from executing
from within IterateElements.
R=ishell@chromium.orgR=cbruni@chromium.org
Bug: chromium:1195977
Change-Id: Ie59d468b73b94818cea986a3ded0804f6dddd10b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2819941
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73898}
This reverts commit d5457f5fb7.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/32999
Original change's description:
> [api] JSFunction PromiseHook for v8::Context
>
> This will enable Node.js to get much better performance from async_hooks
> as currently PromiseHook delegates to C++ for the hook function and then
> Node.js delegates it right back to JavaScript, introducing several
> unnecessary barrier hops in code that gets called very, very frequently
> in modern, promise-heavy applications.
>
> This API mirrors the form of the original C++ function based PromiseHook
> API, however it is intentionally separate to allow it to use JSFunctions
> triggered within generated code to, as much as possible, avoid entering
> runtime functions entirely.
>
> Because PromiseHook has internal use also, beyond just the Node.js use,
> I have opted to leave the existing API intact and keep this separate to
> avoid conflicting with any possible behaviour expectations of other API
> users.
>
> The design ideas for this new API stemmed from discussion with some V8
> team members at a previous Node.js Diagnostics Summit hosted by Google
> in Munich, and the relevant documentation of the discussion can be found
> here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
>
> A summary of the reasons for why this new design is important can be
> found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
>
> Bug: v8:11025
> Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73858}
Bug: v8:11025
Change-Id: Ie7345c4505f39c973f9f0dbca745b591cff63f3f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814740
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73862}
This will enable Node.js to get much better performance from async_hooks
as currently PromiseHook delegates to C++ for the hook function and then
Node.js delegates it right back to JavaScript, introducing several
unnecessary barrier hops in code that gets called very, very frequently
in modern, promise-heavy applications.
This API mirrors the form of the original C++ function based PromiseHook
API, however it is intentionally separate to allow it to use JSFunctions
triggered within generated code to, as much as possible, avoid entering
runtime functions entirely.
Because PromiseHook has internal use also, beyond just the Node.js use,
I have opted to leave the existing API intact and keep this separate to
avoid conflicting with any possible behaviour expectations of other API
users.
The design ideas for this new API stemmed from discussion with some V8
team members at a previous Node.js Diagnostics Summit hosted by Google
in Munich, and the relevant documentation of the discussion can be found
here: https://docs.google.com/document/d/1g8OrG5lMIUhRn1zbkutgY83MiTSMx-0NHDs8Bf-nXxM/edit#heading=h.w1bavzz80l1e
A summary of the reasons for why this new design is important can be
found here: https://docs.google.com/document/d/1vtgoT4_kjgOr-Bl605HR2T6_SC-C8uWzYaOPDK5pmRo/edit?usp=sharing
Bug: v8:11025
Change-Id: I0b403b00c37d3020b5af07b654b860659d3a7697
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2759188
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73858}
In inspector-task.cc, the frontend and backend runners are explicitly
joined before going out-of-scope. On POSIX platforms, calling
pthread_join() on a thread that has already been joined has undefined
behavior. For example, under the musl C runtime library, a successful
call to pthread_join() will unmap the pthread_t thread information
region, and calling pthread_join() again will result in SIGSEGV.
R=clemensb@chromium.org, szuend@chromium.org
Change-Id: Ifdf34ed190df4c722c135ef043a3df588973b984
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2785905
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73699}
toString on JS Proxies are leaking, see this sample code:
undefined[Function.prototype.toString]
undefined[new Proxy(Function.prototype.toString, {})]
This change fixes the behavior.
Patch credits to Yusif <yusif.khudhur@gmail.com>
Change-Id: Id82a0a5c245469973452a3e6609cb91978274b8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739980
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73625}
This patch fixes a segmentation fault which occurs when using `--prof` flag on a Darwin ARM64 architecture.
See https://github.com/nodejs/node/issues/36656
Change-Id: Idc3ce6c8fd8a24f76f1b356f629e37340045b51e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609413
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72886}
This very large changeset adds support for RISC-V.
Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
Extend gen-postmortem-metadata.py with selected register values.
This information is not present in DWARF debuginfo. Exposing it
enables detailed analysis of V8 JS execution by observing binary-level
execution:
https://robert.ocallahan.org/2020/05/omniscient-js-debugging-in-pernosco.html
Bug: v8:11106
Change-Id: I3bde7dd07ac5ba6ff00d4a5fa9b635871507a866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2518957
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71035}
Halve the number of lookups in ExtractLocationForJSFunction() by calling
GetPositionInfo() directly instead of making separate calls for column
and line number.
Improve the efficiency of position lookups in slow mode. The current
code does a linear walk through the source by calling String::Get() for
each character. This PR also does a linear walk, but avoids the overhead
of multiple Get() calls by pulling the String's flat content into a
local vector and walking through that.
Downstream Electron discussion of this can be found at
https://github.com/electron/electron/issues/24509
Apologies in advance if I've missed anything; this is my first V8 CL...
Change-Id: I22b034dc1bfe967164d2f8515a9a0c1d7f043c83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2496065
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70783}
This disables the following features for --enable-third-party-heap:
- inline allocation: all allocation are directed to runtime for now
until we have support for TPH inline allocation.
- allocation site pretenuring: this feature relies on ephemeral
memento objects placed after ordinary objects and is tightly coupled
with V8's GC.
- allocation folding in TurboFan: this feature assumes that objects
of different size and type can be allocated on the same page using
bump-pointer allocation.
Bug: v8:9533
Change-Id: Idbdf1dac566f37db379e5d4b43e0741886f4e69b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463004
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70468}
CreateFrameFromInternal always creates StackFrame from the frame at the index zero,
which is fine for the usage in Trap::origin, but is a bug for Trap::trace
Change-Id: Ia9471f600c5165ffc1c165b2f114b40acbe5b1e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465353
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70465}
The BigInt constructor has quadratic complexity while parsing strings,
and the input is unbounded. Interrupts should be checked during this
operation to ensure the embedder has control over runaway execution.
since the implicit cast from string may now throw.
BigInt: :CompareToString and BigInt::EqualToString now return Maybe<..>
Change-Id: Iccb85fafac4df69075a34d1de647cb4f0184cb12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2392629
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69720}
This reverts commit 825c61d8b4.
Reason for revert: Processing interrupts triggers a DisallowHeapAllocation scope failure.
Original change's description:
> Check interrupts in runtime BigInt parser
>
> The BigInt constructor has quadratic complexity while parsing strings,
> and the input is unbounded. Interrupts should be checked during this
> operation to ensure the host has control over runaway execution.
>
> Change-Id: I15db9adeeafadc7b866a395dd8263aa8c2109ce8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384166
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69679}
TBR=jkummerow@chromium.org,leszeks@chromium.org,marcel@laverdet.com
Bug: chromium:1124477
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I1ba8c1de1f809f71a1c4fae9b56a8bd40f9f7e7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2392815
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69703}
The BigInt constructor has quadratic complexity while parsing strings,
and the input is unbounded. Interrupts should be checked during this
operation to ensure the host has control over runaway execution.
Change-Id: I15db9adeeafadc7b866a395dd8263aa8c2109ce8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384166
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69679}
During spread operation, after VisitForAccumulatorValue,
set the position of the current expression again
Bug: chromium:929844
Change-Id: I6e9ca87587789f9cb21e939d4405414c8170b232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379531
Commit-Queue: HyeockJin Kim <kherootz@gmail.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69677}
