Previously, literals in Torque were stored as double values, which
made it impossible to precisely represent 64 bit integer values.
This CL replaces the old literal expression with an integer and
floating point literal expression that are unbounded in size. We
allow implicit conversion of these literals to arbitary integer
and floating point types respectively and insert a corresponding
bounds check into generated CSA.
Changes in the reland: Simplified IntegerLiteral to single digit.
Bug: v8:7793, chromium:1289282
Change-Id: I31c762c2f31165c7a1d0b07842b764e5851ce189
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406750
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78811}
This CL replaces 'InvalidArgument' with 'ServerError' for
Runtime#getExceptionDetails. The reason is that the error we
raise is on the application level, allowing the DevTools frontend
to handle it to a certain degree. 'InvalidArgument' errors would be
interpreted as "something went really wrong", which is not the case
here.
Bug: chromium:1280141
Change-Id: Id72f06ce8daa06875adeb2528638a80ae61d9e55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420304
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78809}
This is the 1. CL in a series of CollectGarbage refactoring CLs.
Bug:v8:12503
Change-Id: Ia0871df79bf9e1732d6c416079a387cd494196ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3419918
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78807}
Add JumpLoop to the list of bytecodes that unconditionally exit a
block, so that bytecodes are not emitted after a JumpLoop until there's
a bound label.
As a drive by, fix the bytecode random iterator's initialisation to use
'done()' directly (the old condition worked for Return, but was failing
for wide JumpLoops that ended the bytecode).
Change-Id: I63910602efbac8ad2b995a8fe6559a9f8f4b83b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3419919
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78806}
This field points to the start of the WASM memory buffer for the
instance, which is an ArrayBuffer and so guaranteed to be located inside
the sandbox if it is enabled. As such, this simply turns the field into
a sandboxed pointer field.
Bug: chromium:1218005
Change-Id: I847aebf5c29fcf1ab1163809350204db5b685a10
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359630
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78805}
This type is no longer required: all ExternalPointers are now
sandboxified in turbofan, so we use that type instead.
Bug: v8:10391
Change-Id: Ia2bd261bfe3cfd5c7d9c350ba0e553e57a596a42
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359632
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78802}
... because of unaligned field address. The fix is to load code cage
base and the tagged value separately and then decompress - the same way
as it's done in the relaxed accessors of the code field.
Bug: v8:11880
Change-Id: Ia4699458e6a00ee16efea06c48cc5c67a82b22f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416999
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78801}
The functionality is unused and we are simplifying OptimizationMarker
usage.
Drive-by: Remove unused return value of Compiler::CompileOptimized.
Drive-by: Don't add kStackSpaceRequiredForCompilation as gap to the
stack check when compiling concurrently, i.e. on another thread.
Bug: chromium:757467
Change-Id: Ibbe204b82bf937b9eb74f9eb2c3fd2d719d53ef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416245
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78800}
CallFunction is only called for targets that are checked not to be class
constructors, therefore we can remove the check for class constructors
from CallFunction.
Change-Id: I3157b885a47f453003201be6ceb0763f7ccbcbf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416243
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78799}
The existing NumberConstant helper subsumes the recently introduced
SmiConstant (because it produces Smis when it can), so there is no
need for the latter.
Change-Id: Ia49d2c9298c6e75a6465b3b6a68745f4de899671
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416240
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78798}
This is a reland of 5320fe8d58
Changes since revert:
- Remove stale DCHECK in deserializer
Original change's description:
> Reland "[string] Support shared strings in Value{Serializer,Deserializer}"
>
> This is a reland of 3cb4039cd1
>
> Changes since revert:
> - Fix FLAG_stress_scavenge interaction with shared Isolate
> - Use the shared Isolate's global handles to keep shared values
> alive in transit during a postMessage
>
> Original change's description:
> > [string] Support shared strings in Value{Serializer,Deserializer}
> >
> > When FLAG_shared_string_table is true, postMessaging strings will share
> > instead of copy.
> >
> > Note that not all operations on shared strings are supported, and shared
> > strings may be slower than non-shared strings for some operations.
Bug: v8:12007
Change-Id: I70782978ed05558615eca03bafc4c12eba3644ca
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417189
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78791}
Implementations are added to macro-assembler to be shared between
liftoff and TF code generator.
Change-Id: I0d1c9e8bcd2dfd89b5ed4a273821766763565f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3417438
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78790}
Create and return the chained promise, which resumes the suspended wasm
continuation once the JS promise resolves:
- Add stub for the WasmResume builtin, which will resume the given
suspender.
- Add the JS function wrapper for the builtin.
- On suspension, return promise.then(onFulfilled) to the prompt.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I2d6136b2bd610daa4be1880f347b7bdf897e75ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404776
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78787}
Moves g_root_vmar_base up in the file, so that we have all
the globals together.
Bug: v8:11232
Change-Id: Ic08cdf3399982962de255028be6718951a17aedb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416249
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78786}
When reparsing the class scope to collect initializers in sloppy mode,
the class scope may still have a scope info without any allocated
variables. If its outer scope doesn't have an outer scope (which means
the outer scope in the optimized scope chain becomes the script scope),
we should also set the scope info in the script scope as is done
in Scope::DeserializeScopeChain() for the scope resolution.
Bug: chromium:1290587, v8:10704
Change-Id: I7804d53f330e59d4ab0405a11b132569f348b55d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3413647
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78784}
This patch takes advantage of memory information from the module
to avoid unnecessary reloads of the SSA environment after a Wasm call.
As far as I can sse, the SSA envinronment consists of the mem_start
and mem_size values. Both these values cannot ever change if:
initial_mem_size == max_mem_size.
Although this should be obviously true for memories defined in the
module itself, some explanation may be necessary for imported memories.
During module instantiation, the imported memory is checked as part of
InstanceBuilder::ProcessImportedMemory. The following properties are verified:
1) The current size of the imported memory is >= the initial declared size
2) The maximal size of the imported memory is <= the maximal declared size
The effective maximal limit will be min(imported_max, declared_max),
hence the optimization will only trigger if the imported memory is
already as large as it can be.
Since memory growth is impossible, there is no point in reloading the
environment anyway.
Change-Id: Ie6c6ad278175d253b61131972a6db7530bd52b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412082
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78782}
On AIX, calling mmap on a pre-designated address with
MAP_FIXED will fail and return -1 unless the application
has requested SPEC1170 compliant behaviour with arguments
such as `XPG_SUS_ENV=ON`.
Therefore an AIX specific implementation has been added under
platform-aix.cc.
Change-Id: Ib5b8a19a3a9e6d202aed7e792c00a25ddc547c72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3403045
Reviewed-by: Samuel Groß <saelo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78778}
1) when generating short builtin calls/jumps assemblers should use the
offset from the CodeRange base rather than the start of the code
range reservation because otherwise it's not guaranteed that the
PC-relative offset will fit into architecture's constraints.
The code range reservation start could be different from the code
range base in the following cases:
* when the "base bias size" is non-zero (on Windows 64),
* when we ended up over-reserving the address space for the code
range, which happens as a last resort to fulfil the CodeRange
alignment requirements.
See the VirtualMemoryCage description for details.
Drive-by fixes:
2) in case of over-reserving address space for external code range,
the pre-calculated hint for where the remapped embedded builtins
should be copied to was outside of the allocatable CodeRange region
and thus useless. The fix is to use the allocatable region instead
of the reservation region when calculating the hint.
3) when allocating CodeRange with zero base bias size we can create
the VirtualMemory reservation from the first attempt simply by
passing the required base alignment to the VirtualMemory
constructor.
Bug: v8:11880, chromium:1290591
Change-Id: If341418947e2170d967e22b38bcc371594939c1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412089
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78772}
Map::Hash relies on the fact that the map space is never compacted.
However this might change in the future, so instead of using the
address of the prototype's map, we use the prototype's identity hash
instead.
Bug: v8:12578
Change-Id: Ia4961ed55119681c0033aa187789f6710ff2d22c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412085
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78768}
Exports are properties in the global object. Pre-reserve the space,
since we know the count upfront.
Bug: v8:11525
Change-Id: Ia8ea992234ed8cf71a1060254766b0ba31562436
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416231
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78767}
In current BitwiseSmi bytecodes the code to do Smi operation is inside a
loop. This CL fast path the Smi operation by peeling the first Smi check
out of the loop, and avoid Smi->Int->Smi conversion where possible.
Drive-by fix: Add CSA_DCHECK in Smi shift to avoid unexpected use.
Bug: v8:12442
Change-Id: I1adce560fb22a4409337e2958779eccf9197e4ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328784
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Cr-Commit-Position: refs/heads/main@{#78764}
- Use raw pointer when setting the SFI in CreateJSFunction
- Use some more factory->xxx_value() handle accessor to avoid handle
creation
Bug: v8:11525
Change-Id: I5ed62f56cf2e53cc765566c0c129c7851b704813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401591
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78763}
