This CL fixes a bug that allowed OOB read/stores on fastpaths when
a comparison function caused the underlying FixedArray to change
while keeping the elements kinds and size property on the original
JSArray the same.
R=jgruber@chromium.org
Bug: chromium:852592
Change-Id: I09af357d10e7f41e75241e4c87430fc9aa806f8c
Reviewed-on: https://chromium-review.googlesource.com/1104158
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53811}
This reverts commit 733b7c8258.
Reason for revert: breaks arm64 gc-stress: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/11659
Original change's description:
> [wasm] Introduce jump table
>
> This introduces the concept of a jump table for WebAssembly, which is
> used for every direct and indirect call to any WebAssembly function.
> For lazy compilation, it will initially contain code to call the
> WasmCompileLazy builtin, where it passes the function index to be
> called.
> For non-lazy-compilation, it will contain a jump to the actual code.
> The jump table allows to easily redirect functions for lazy
> compilation, tier-up, debugging and (in the future) code aging. After
> this CL, we will not need to patch existing code any more for any of
> these operations.
>
> R=mstarzinger@chromium.org, titzer@chromium.org
>
> Bug: v8:7758
> Change-Id: I45f9983c2b06ae81bf5ce9847f4542fb48844a4f
> Reviewed-on: https://chromium-review.googlesource.com/1097075
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53805}
TBR=mstarzinger@chromium.org,titzer@chromium.org,clemensh@chromium.org,sreten.kovacevic@mips.com
Change-Id: Iea358db2cf13656a65cf69a6d82cbbc10d3e7e1c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7758
Reviewed-on: https://chromium-review.googlesource.com/1105157
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53807}
Now TFJ builtins can use their own descriptors so there's no need to
keep the hacky BuiltinDescriptor around.
Bug: v8:7754
Change-Id: Ia7f23a21fb979370fd2149fef13186b83a3d5d30
Reviewed-on: https://chromium-review.googlesource.com/1104428
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53806}
This introduces the concept of a jump table for WebAssembly, which is
used for every direct and indirect call to any WebAssembly function.
For lazy compilation, it will initially contain code to call the
WasmCompileLazy builtin, where it passes the function index to be
called.
For non-lazy-compilation, it will contain a jump to the actual code.
The jump table allows to easily redirect functions for lazy
compilation, tier-up, debugging and (in the future) code aging. After
this CL, we will not need to patch existing code any more for any of
these operations.
R=mstarzinger@chromium.org, titzer@chromium.org
Bug: v8:7758
Change-Id: I45f9983c2b06ae81bf5ce9847f4542fb48844a4f
Reviewed-on: https://chromium-review.googlesource.com/1097075
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53805}
Move Slot recording to concurrent and incremental marking phase and
out of the atomic pause. Records more slots to remove
slot recording completely from the pause.
Bug: chromium:844008
Change-Id: I13ba20b4839990134dc37bd909fb0a2d66e13c64
Reviewed-on: https://chromium-review.googlesource.com/1104348
Commit-Queue: Dominik Inführ <dinfuehr@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53804}
Currently each isolate stores its own array of
{CallInterfaceDescriptorData}. This array has size 173, and each entry
has 40 bytes. That's already 7kB per isolate.
Additionally, each {CallInterfaceDescriptorData} allocates two
heap-allocated arrays, which probably add up to more than the static
size of the {CallInterfaceDescriptorData}. Note that all the
{CallInterfaceDescriptorData} instances are initialized eagerly on
isolate creation.
Since {CallInterfaceDescriptor} is totally isolate independent itself,
this CL refactors the current design to avoid a copy of them per
isolate, and instead shares them process-wide. Still, we need to free
the allocated heap arrays when the last isolate dies to avoid leaks.
This can probably be refactored later by statically initializing more
and avoiding the heap allocations all together.
This refactoring will also allow us to use {CallInterfaceDescriptor}s
from wasm background compilation threads, which are not bound to any
isolate.
R=mstarzinger@chromium.org, titzer@chromium.org
Bug: v8:6600
Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
Reviewed-on: https://chromium-review.googlesource.com/1100879
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53803}
For now we keep params since NewSloppyArguments uses it to figure out how to structure the arguments object. We should be able to only keep params in case we have a special case though. E.g., leaf functions with no duplicate parameters don't need special treatment. Or we simply encode the parameter index for each context slot. (I'm not sure duplicates need special treatment.)
Change-Id: Icfbb844e5331aeb93c50bc07edd58246c8aeb1d7
Reviewed-on: https://chromium-review.googlesource.com/1104420
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53802}
We currently store the {WasmModule} (generated during decoding) in a
unique_ptr and pass ownership to the {WasmModuleObject} after
compilation.
I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to
{WasmModuleObject}, which will force us to create the
{WasmModuleObject} *before* compilation, so that the {CompilationState}
is available during compilation.
This CL prepares that refactoring by storing the {WasmModule} in a
{shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be
stored in a {shared_ptr} in the {Managed} anyway.
R=titzer@chromium.org
Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a
Reviewed-on: https://chromium-review.googlesource.com/1104117
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53801}
This CL completely reimplements the DataView setters in Torque, and
removes the former C++ runtime implementation.
Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf
Reviewed-on: https://chromium-review.googlesource.com/1104162
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53800}
Reading up on the bug description, this is a test
that is triggered by TurboFan execution. This can
be done with natives and does not need excessive
loop iterations. Additionally, we have a more specific
regression test for the original issue in the repo:
http://crrev.com/c/584837
Bug: v8:7783
Change-Id: Id022b515b663e6fb897acb29f43ef92b70b547b8
Reviewed-on: https://chromium-review.googlesource.com/1101018
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53799}
This adds an overload of JSGraph::Constant that takes an ObjectReference
rather than a Handle<Object>.
ObjectReference is a new superclass of HeapReference.
Also several refactorings and renaming, e.g.:
- Rename HeapReference to HeapObjectRef.
- Rename ContextHeapReference to ContextRef.
- ...
- Rename HeapReferenceType to HeapObjectType.
Bug: v8:7790
Change-Id: Id3e567cbaf7c326189b99b2fd4ced6bff02f9640
Reviewed-on: https://chromium-review.googlesource.com/1104337
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53797}
This CL also adds macros for defining JS-compatible interface descriptors that
has additional parameters.
ArrayConstructorDescriptor is redefined using the new macros.
Bug: v8:7754
Change-Id: Id39cac9f234666576f35de755d11aba198248bea
Reviewed-on: https://chromium-review.googlesource.com/1100833
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53796}
The test test-api/InitializeDefaultIsolateOnSecondaryThread1 has been
failing since at least 6.8, but our infra only recently realized that.
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
Bug: v8:7856
Change-Id: I8cbfd4ea554bb32c50c01d437efa5b18f60c2fde
Reviewed-on: https://chromium-review.googlesource.com/1104458
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53795}
This is a preliminary step before removing BuiltinDescriptor.
Bug: v8:7754
Change-Id: I752134aa29431e5773c9813361a3c6bda6f8872d
Reviewed-on: https://chromium-review.googlesource.com/1104169
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53794}
The operator<< for Signature objects in Torque incorrectly counted
the number of named parameters instead of the total number
of parameters when displaying them.
This would cause the displayed signature to be "()" when no
parameters were named, instead of the actual signature.
Change-Id: I32572da5f5a378b71749515d89429172129bbcb9
Reviewed-on: https://chromium-review.googlesource.com/1104172
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Théotime Grohens <theotime@google.com>
Cr-Commit-Position: refs/heads/master@{#53792}
We currently have a system where the protected instructions are
unregistered when the last instance dies, and registered again on the
next instantiation. This is triggered by {WasmCompiledModule::Reset}.
Since the reference to the {NativeModule} will move to the
{WasmModuleObject}, and this object stays alive even if the last
instance dies, this will become hard to maintain.
It will also make it harder to share wasm code across isolates.
This CL refactors this to register trap handler data once when the code
is added to the {NativeModule}, and releases it if the code dies.
R=mstarzinger@chromium.org
CC=eholk@chromium.org
Bug: v8:5277
Change-Id: I3f1b336095230b255f3849c271b37b62f2b96cd6
Reviewed-on: https://chromium-review.googlesource.com/1103567
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53791}
This is a step towards avoiding materializing function_ altogether if we deoptimize. Typically we only need the SharedFunctionInfo.
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Idee78f02d1afe3d2cb70e93a6d96a5a33907f892
Reviewed-on: https://chromium-review.googlesource.com/1100474
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53789}
It only has one call size ({CompileToModuleObject}), which just tail
calls into {CompileToModuleObjectInternal}. Thus, merge the two.
R=titzer@chromium.org
Bug: v8:7754
Change-Id: I6344f257279f049fd6cab51114988f7e1c019272
Reviewed-on: https://chromium-review.googlesource.com/1104157
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53787}
Instead of instantiating each function multiple times, just call out to
a common function, passing the variadic number of arguments in an
initializer list.
R=tebbi@chromium.org
Bug: v8:7754
Change-Id: Idb2d77cef7cf8e590de6aa3cea02c0e0773da45f
Reviewed-on: https://chromium-review.googlesource.com/1101689
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53785}
Return the raw Object* when accessing the constant pool of bytecode
with the bytecode array accessor, to avoid needing an isolate there.
If the returned value needs to be a handle, we create the handle
later.
Bug: v8:7786
Change-Id: Ifeac2a06f0383230bf7e9bfc1b751d9750ecfb51
Reviewed-on: https://chromium-review.googlesource.com/1102334
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53784}
By now we no longer emit calls with {RelocInfo::CODE_TARGET} as part of
WebAssembly code. Hence the requirement to block sharing of code targets
disappeared and the support can be dropped.
R=jarin@chromium.org
Change-Id: I6df026cd05769ddaa6ea8df5a7b17b62e8a7c373
Reviewed-on: https://chromium-review.googlesource.com/1100889
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53782}
Current situation: When calling a macro with the wrong parameter types
the error message will say "macro not found".
This CL changes the message to "macro with parameter types not found"
and lists possible candidates.
R=tebbi@chromium.org
Bug: v8:7793
Change-Id: I6724c4030cbbf4ca1af008b33797b2dd9d18808b
Reviewed-on: https://chromium-review.googlesource.com/1101694
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53780}
The FuzzAssemble* tests rely on two CSA functions which are relatively big. And
with the --enable-slow-asserts flag they get so big that the register
allocator's memory consumption becomes a problem. Let's just override this flag.
Bug: v8:7819, v8:6848, v8:7842
Change-Id: I95db59b9c788aa665d04339892b2e0b5d92d9a89
Reviewed-on: https://chromium-review.googlesource.com/1093315
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#53779}
Since https://crrev.com/2951473002, there is only one reloc info for
code targets, so there is no need for the special {kCodeTargetMask}.
R=mstarzinger@chromium.org
Bug: v8:7754
Change-Id: I1055108c0128c7de0f5cfefc5e90bbd9dc75522a
Reviewed-on: https://chromium-review.googlesource.com/1098663
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53776}
The jump optimization maybe run Turbofan pipeline twice for each TF/CS builtins,
and relies on the fact that the number of j/jmp instruction generated is always
the same.
This CL introduces a verification process to ensure that instruction sequence
and virtual registers are always the same in two stages, before the final
code generation phase.
R=danno@chromium.org, jarin@chromium.org
Bug: v8:7839
Change-Id: Id77e9bc80f54f79d7a845315e0b99e3f4b6a54fb
Reviewed-on: https://chromium-review.googlesource.com/1100491
Commit-Queue: Kanghua Yu <kanghua.yu@intel.com>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53774}
This reverts two commits:
Introduce CodeAssembler::LoadRootsPointer
377803f804
[turbofan][x64] Reduce reg-to-reg moving instruction for
LoadRootsRegister IR
d4177d1173
LoadRootsPointer was used by indirections for heap constants and
external references from within CSA. Now that handling has moved to
the macro-assembler, it can be removed.
Bug: v8:6666
Change-Id: I868fe100e65a0a7a44ffc81674fa1ce79a56f7ed
Reviewed-on: https://chromium-review.googlesource.com/1097080
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53770}
This CL moves the remaining runtime DataView getters to Torque,
namely DataViewGetBigInt64/BigUint64, and removes the associated
runtime code that is now unneeded.
All of the DataView getters are now implemented in Torque, which brings
a nice performance improvement over the former C++ builtin code.
Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804
Reviewed-on: https://chromium-review.googlesource.com/1092736
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53765}
{LogWasmCodes} is independent of the runtime object, so it should be
defined on the {NativeModule}.
R=herhut@chromium.org
Change-Id: I1202b18264ef0367004ba80e0030b057c633b62f
Reviewed-on: https://chromium-review.googlesource.com/1102424
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53764}
We currently create a managed object holding a shared reference to the
WasmModule, and pass this to the factory method for the
WasmModuleObject. Instead, we can just create it inside that factory
method, removing code duplication.
R=herhut@chromium.org
Change-Id: I3cea858ba445971dc8dbeb693061ef5684bc02da
Reviewed-on: https://chromium-review.googlesource.com/1102336
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53763}
Instead of just {Object}, this field can be typed as
{Managed<wasm::Module>}.
R=herhut@chromium.org
Change-Id: Iad47f75ae823846394b6ad04e8829961e924f33d
Reviewed-on: https://chromium-review.googlesource.com/1102333
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53762}
