This implements the proper semantics for matching exported/imported
exceptions by using the notion of an "exception tag" that is global to
the system. It can be used to match exceptions in one module against
exceptions declared and/or thrown in another module (or instance).
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-shared
BUG=v8:8091
Change-Id: I37586d7be5d5e6169b3418dfbc415b26dd4750dd
Reviewed-on: https://chromium-review.googlesource.com/1226976
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55940}
Reduce the number of workers in the atomic compare-exchange test to
make it run faster on systems with few cores.
Bug: v8:8164
Change-Id: I4de22863e1f2a44d9da4416161d08f5acfcece22
Reviewed-on: https://chromium-review.googlesource.com/1224771
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55887}
This also fixes a use where it should be a public name. For public
names, we use what is defined in the module or wasm-function[%d] as per
the wasm names spec.
Bug: v8:8015
Change-Id: Ie102db4e1114b20caeb4a990cb9e07cacf0666bc
Reviewed-on: https://chromium-review.googlesource.com/1215627
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55827}
This checks the type signature during import against the expected
signature. For this the {WasmExceptionObject} now contains a serialized
version of the signature.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-import
BUG=v8:8091
Change-Id: I5a34ef87eccf4d2ed3a784620796ec009623fd90
Reviewed-on: https://chromium-review.googlesource.com/1219509
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55789}
There was a bug in WebAssembly.instantiate in the case where a CSP
disallows WebAssembly compilation. In this case the promise returned by
WebAssembly.instantiate was rejected immediately because of the CSP,
but then compilation was started anyways, and the promise was resolved
after compilation for a second time, which caused the crash. With this
CL we do not start compilation if CSP disallows WebAssembly compilation.
R=clemensh@chromium.org
Bug: chromium:881978
Change-Id: Iffdb3e02c3006eb7f86211ab197f81cf20438f0e
Reviewed-on: https://chromium-review.googlesource.com/1219706
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55788}
This adds the ability to import exception into a module at instantiation
time. Only a {WasmExceptionObject} that has been exported by another
module instance can be imported, all other values are rejected.
Note that currently there is no signature check being performed to make
sure the imported exception matches the expected type. Also the identity
of imported exceptions is not yet preserved.
Furthermore the engine does not yet match thrown exception objects on a
global level across modules. Hence imported exceptions will (wrongly)
behave as completely new types within the module.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-import,unittests/WasmModuleVerifyTest
BUG=v8:8091
Change-Id: If247762b949a1ba4a87d13bc3e790a45dbc67815
Reviewed-on: https://chromium-review.googlesource.com/1216402
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55777}
This new instance type will be used for wrapper objects representing
exported exceptions. Currently the objects are empty and only serve as
an identity for exported exceptions. Eventually they will also need to
reference the signature underlying the exception to perform a signature
check upon import.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-import
BUG=v8:8091
Change-Id: Ifdd561fc000090f4a985aeb45549fd7110849646
Reviewed-on: https://chromium-review.googlesource.com/1215166
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55752}
Add a test that runs multiple workers that concurrently try to advance
along a random sequence of numbers, using AtomicCompareExchange to
update the shared current position.
Change-Id: Ie073bbdce6fd6766ef1f73f996dd592b90b8b3c2
Reviewed-on: https://chromium-review.googlesource.com/1198769
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55722}
This adds the ability to add exception types to the export section of a
module and reference them via the local exception index. Currently the
export object then just contains the local index as a number, which is
only temporary until we have proper export wrappers for exceptions.
Also note that this tightens the restriction for the modules exception
section to be located in between the import and the export section.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-export
BUG=v8:8091
Change-Id: Ie26081c3f94e71cb576057db7e45ec5bd0e112f9
Reviewed-on: https://chromium-review.googlesource.com/1206873
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55679}
This fixes an off-by-one in the ordering restriction check for exception
sections in a module. It also adds proper testing for exception handling
of indirect calls. This in turn adds a table section that triggers the
aforementioned bug.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions,unittests/WasmModuleVerifyTest
BUG=v8:8091
Change-Id: Ie44ad4dee1b0c623f069fca7661c4282492b52d6
Reviewed-on: https://chromium-review.googlesource.com/1203993
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55615}
This fixes exception creation (by the WebAssembly throw operation) so
that it is not observable by JavaScript. Internal properties are now
stored with symbol names instead of string names, which also prevents
them from being accessed or monkey-patched directly by JavaScript.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-8094
BUG=v8:8094
Change-Id: I33cb27f4373114cd4db28d9aef23560093e55242
Reviewed-on: https://chromium-review.googlesource.com/1203951
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55602}
This CL fixes a bug where the receiving instance was updated improperly
in the dispatch table(s) of an imported table.
BUG=chromium:875322
R=mstarzinger@chromium.org
Change-Id: Ib5af238a0847bf332a12863523e897f59f137c1d
Reviewed-on: https://chromium-review.googlesource.com/1196886
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55534}
This adds experimental support for an 'except_ref' value type for caught
exceptions as per the exception handling proposal. In the current for it
is only allowed to have such types in the stack or in a local, support
for having it as part of any signature was left out.
The default value for a local of type 'except_ref' is the 'ref_null'
value for now. Since this value cannot escape a wasm function, the
concrete value is not actually observable.
R=ahaas@chromium.org
TEST=unittests/LocalDeclDecoderTest.ExceptRef,mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: I7bd65274327a833262f8749cbe0e24e737f6e0c1
Reviewed-on: https://chromium-review.googlesource.com/1196510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55526}
It is better not to have V8-specific constants in mjsunit.js because it
also has V8-independent uses, e.g. in the spec tests.
R=gdeepti@chromium.org
Bug: v8:8015
Change-Id: I3b576f093f639c13e673cbd0bd5305c8101d7281
Reviewed-on: https://chromium-review.googlesource.com/1192843
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55485}
This makes sure that direct and indirect calls get proper {IfException}
projections attached to them if they appear within a try-block. It also
re-enables most of the corresponding test cases for this.
R=ahaas@chromium.org
TEST=mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: I111634759651ed47f76850e80c8754751310001b
Reviewed-on: https://chromium-review.googlesource.com/1195365
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55483}
This makes sure that debug info and interpreter handle are created
lazily, even when interpretation is triggered by a different Isolate
sharing the same WasmEngine (and hence the native module).
R=titzer@chromium.org
TEST=mjsunit/wasm/worker-interpreter
BUG=v8:7424
Change-Id: Iba17e207a537007fd2e642cede22dad7a708c6c7
Reviewed-on: https://chromium-review.googlesource.com/1181045
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55220}
This makes sure that a tier-up from Ignition to TurboFan (or any other
code publishing) preserves redirections to the Interpreter. Currently an
interpreted function never switches back to compiled.
R=titzer@chromium.org
TEST=mjsunit/wasm/interpreter-mixed
BUG=v8:7921,v8:8018
Change-Id: Ifca479953509708c998c11cc00b481c232678e00
Reviewed-on: https://chromium-review.googlesource.com/1179661
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55195}
Enforce both engine limitations and spec (http://asmjs.org/spec/latest/)
limitations on the size of asm.js heaps.
R=clemensh@chromium.org
CC=mstarzinger@chromium.org
Bug: chromium:873600
Change-Id: I104c23bbd0a9a7c494f97f8f9e83ac5a37496dfd
Reviewed-on: https://chromium-review.googlesource.com/1174411
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55163}
With the origin trial for WebAssembly threads, threads can be turned on
and off by the embedder depending on the context we are currently in.
With this CL we call the embedder callback stored on the isolate to
determine whether threads are enabled in the current context or not.
Design decision:
I decided to extend the {WasmFeaturesFromIsolate} function to ask the
embedder if WebAssembly threads are enabled. This is the function which
defines dynamically which features are turned on. It would be awkward
to have two such functions, one which calls the embedder and one which
does not.
A downside is that in WasmJs::Install the embedder does not seem to be
ready to be called. That's why I changed the code there to call
{WasmFeaturesFromFlags} instead.
R=titzer@chromium.org, mstarzinger@chromium.org
Bug: chromium:868844
Change-Id: I6bfa89960a54cec71992756e3717bbb3a9fe195e
Reviewed-on: https://chromium-review.googlesource.com/1169180
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55076}
For async instantiation of WebAssembly code we had the assumption that
a pending exceptions (an exception which comes from
execution JS code) and an ErrorThrower error cannot occur at the same
time. This assumption turned out to be wrong. With this CL we handle
this case by prefering pending_exceptions over ErrorThrower errors.
In addition I extended the tests for failing instantiation to also
exercise async instantiation, and I added a regression test.
R=clemensh@chromium.org
Bug: chromium:870646
Change-Id: I4cb54ff8642ad4ea193b20f79905c9f6508c2b2e
Reviewed-on: https://chromium-review.googlesource.com/1163511
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54940}
All compile tasks are already canceled when the {CompilationState}
dies. This happens when the {NativeModule} dies, and all
{NativeModule}s die before the {WasmEngine} dies. Thus, the WasmEngine
does not need to cancel any compile jobs, because there are none anyway.
R=mstarzinger@chromium.org
Bug: chromium:869420
Change-Id: I7e006392a1f9126333733c81c4c19985f626a470
Reviewed-on: https://chromium-review.googlesource.com/1158411
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54840}
Add codegen support for up to 4GiB memories in Liftoff code.
This CL also adds three new mjsunit tests that stress large WASM
memories (1, 2, and 4 GiB) and checks that accesses near these
boundaries properly generate traps.
Note there is still some trickiness around the setting of:
1.) the flag --wasm-max-mem-pages
2.) wasm-limits.h kSpecMaxWasmMemoryPages = 65536
3.) wasm-limits.h kV8MaxWasmMemoryPages = 32767
In particular, the allocation of memories is still limited to
3.) and the runtime flag can only lower this limit.
The above means that the tests for 2GiB and 4GiB memories will silently
OOM by design until 3.) is changed (though they currently pass with
manual testing). I argue it is better to include these tests up front,
since they will immediately trigger if their memory allocation succeeds.
Therefore the plan is to lift the restriction on 3.) after removing
all other other internal V8 limitations including array buffers and views.
R=clemensh@chromium.orgCC=mstarzinger@chromium.org
BUG=v8:7881
Change-Id: I3205ac2daf5c9a84364c670a2c3ef2258e5649f6
Reviewed-on: https://chromium-review.googlesource.com/1151309
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54754}
This reverts commit 53fe5c4485.
Reason for revert: Test can be re-enabled, a fix for the flake landed by now.
Original change's description:
> [wasm] Temporarily disable --wasm-shared-engine test.
>
> R=leszeks@chromium.org
>
> Change-Id: Ib037c43571cda0e2da3c6da3d763cfe27c797413
> Reviewed-on: https://chromium-review.googlesource.com/1150033
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54692}
TBR=mstarzinger@chromium.org,leszeks@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I406740898d896a18eef365cdd20581d5de84023a
Reviewed-on: https://chromium-review.googlesource.com/1151407
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54731}
This flag allows to share a single WasmEngine among all Isolates within
the same process. It will ultimately allow to share the WasmCode objects
associated with modules that are transferred via structured cloning.
R=clemensh@chromium.org
TEST=mjsunit/wasm/worker-module
BUG=v8:7424
Change-Id: I70d852d319b2a80bd02e0a2a838dcdfa071df6e1
Reviewed-on: https://chromium-review.googlesource.com/1138213
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54678}
This is a preparatory CL that refactors the WASM memory allocation path,
the WasmGraphBuilder, and several points of contact for ArrayBuffers to
allow them to eventually be up to 4GiB.
1.) Refactor definition of constants to prepare for memories of size 2^32
2.) Refactor WasmInstanceObject fields memory_size and memory_mask to
be stored as uintptr_t
3.) Refactor WasmGraphBuilder to use 64-bit comparisons for bounds checks
4.) Refactor JSArrayBuffer accessor methods to use size_t properly.
5.) Add empirical maximum memory and array buffer size tests
R=mstarzinger@chromium.org
BUG=v8:7881
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I78a49069cfa89757cc93f0a30b1c1a99c4b2edba
Reviewed-on: https://chromium-review.googlesource.com/1112003
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54646}
Currently the fuzzer only tests Turbofan and Liftoff in isolation. In
order to test that both tiers use the same ABI, it should also test
calls from one tier to the other.
This CL introduces a new flag which controls which function will be
compiled by which tier, and uses that in the fuzzer.
R=ahaas@chromium.org
Bug: chromium:862931, v8:6600
Change-Id: I450b906700972cfdb496b1734faed9f8208d652f
Reviewed-on: https://chromium-review.googlesource.com/1134775
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54409}
When calling an import which is an exported wasm function, the
interpreter needs to look through the jump table to find the
actual code object.
We already had that logic for indirect calls, but it was missing for
imported calls.
R=ahaas@chromium.org
Bug: chromium:860392
Change-Id: I6b5a0192f79c23cb1de55407fe93f6df9a17235a
Reviewed-on: https://chromium-review.googlesource.com/1127671
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54291}
This correctly serializes {RelocInfo::INTERNAL_REFERENCE} addresses in a
position-independent form, so that they can be properly relocated when
the code is deserialized again. We store the offset within the code in
the serialized stream.
R=clemensh@chromium.org
TEST=mjsunit/wasm/compiled-module-serialization
BUG=chromium:857049
Change-Id: Ie8c84ee67bdfc17a65faa159a21cc1f2a78ac924
Reviewed-on: https://chromium-review.googlesource.com/1122414
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54140}
This makes sure the reverse tag translation of direct call targets to
respective call tags is properly performed. Otherwise all direct call
end up being deserialized to call the function with index '0'. Ooops!
R=clemensh@chromium.org
TEST=mjsunit/wasm/compiled-module-serialization
BUG=chromium:857049
Change-Id: I37c1ee72b000daec87efdeed08d60a067b1a1b0c
Reviewed-on: https://chromium-review.googlesource.com/1120256
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54124}
Supporting postMessage from WebAssembly.Module requires implementing
some logic in the ValueSerializer and ValueDeserializer delegates. This
change implements some simple logic for d8.
This change also fixes a DCHECK that occurs when sending a shared
WebAssembly.Memory object to two Workers.
Bug: chromium:857049
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Idddb23a48175c7175967af3fbc03d8572452a069
Reviewed-on: https://chromium-review.googlesource.com/1117871
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54093}
Before flipping the flag, some tests need to be adapted. This CL
prepares these tests, such that the flag flip CL really just flips a
flag.
R=titzer@chromium.org, hablich@chromium.org
Bug: v8:6600, chromium:787421
Change-Id: I8030df69cda5f3fb81354350a37f65c0d1c669bd
Reviewed-on: https://chromium-review.googlesource.com/1110363
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53959}
We assumed that if the ErrorThrower is empty after instantiation, then
instantiation succeeded and an instance exists which we can return.
However, if the start function throws, no instance exists, which caused
a crash. With this CL we handle execeptions thrown by the start
function correctly.
R=clemensh@chromium.org
Bug: chromium:848966
Change-Id: I51dc94e6bc563aa4a4b88c44a14e831af913fbd8
Reviewed-on: https://chromium-review.googlesource.com/1092234
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53687}
Mutable globals are now included in the wasm v1 spec.
Bug: v8:7625
Change-Id: Ib9b92d8348102f99a3b92820d0057b2c11a1e49a
Reviewed-on: https://chromium-review.googlesource.com/1095650
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53683}
Mutable globals are stored in the instance differently, so they must be
exported differently as well.
Also fix a counting bug that occurred when a module contained a global
and an imported mutable global (CalculateGlobalOffsets is called
twice).
Bug: v8:7625
Change-Id: I1cd7ef5d6ff7cb7e09239035f89d7b36d0436063
Reviewed-on: https://chromium-review.googlesource.com/1096673
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53681}
This CL adds the simplest version of a trap handler fallback. At
instantiation time, we check whether the module was compiled to use
trap handlers and the memory is guarded. If the memory is not guarded
but the module is supposed to use trap handlers, we recompile the
module with bounds checks so that we can use an unguarded memory.
The compiled module is replaced with a bounds checking version, meaning
future instances from this module will also use bounds checks.
Some likely desirable features that are current missing but can be
added future CLs include:
* Disabling trap handler mode entirely.
* Recompiling all old instances so that trap handler and bounds checked
code does not coexist in the same process.
Bug: v8:7143
Change-Id: I161fc0d544133b07dc4a93cc6af813369aaf3efe
Reviewed-on: https://chromium-review.googlesource.com/1018182
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53566}
The typical use of assertThrowsEquals is to check that a specific
object is thrown. However, assertEquals only does a proper equality
check for primitive types, not for complex types. Using assertSame
does a reference equality check on objects, which is more what you
would expect from assertThrowsEquals. For exception kind testing,
assertThrowsEquals actually did not work correctly, assertThrows is
better for that case.
R=clemensh@chromium.org, mythria@chromium.org
Change-Id: I24fb22e75fa33ebe90eb4bae40825119a054bba5
Reviewed-on: https://chromium-review.googlesource.com/1087952
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53556}
This makes stack checks in WasmCode independent of the underlying
Isolate by loading the limit address from the WasmInstanceObject instead
of embedding it into the instruction stream. It hence removes the last
use of the Isolate field from WasmGraphBuilder.
Additionally this introduces the notion of a "runtime stub" which
represents stub code global to the NativeModule that can be directly
called from each WasmCode in the same module. These stubs can act as
trampolines via which Isolate-independent WasmCode can enter other V8
builtins or runtime functions that remain Isolate-dependent. They will
eventually replace the current "trampoline" in a NativeModule.
R=titzer@chromium.org
BUG=v8:7424
Change-Id: Ie1f5582ee656b1ab7716ea06316d6e21a0268e74
Reviewed-on: https://chromium-review.googlesource.com/1078732
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53487}
This was renamed recently in the spec.
Change-Id: I825e47e8b4113ddb2c3356ee8e7663705ba65e1c
Reviewed-on: https://chromium-review.googlesource.com/1079851
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53448}
We were always using the instance we were currently building. If the
start function is an exported wasm function of another instance, use the
exporting instance instead.
R=titzer@chromium.org
Bug: chromium:843120
Change-Id: I141d272b947bef8e903be7208ddf6ce344e754c4
Reviewed-on: https://chromium-review.googlesource.com/1059620
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53190}
Since the code around that is quite fragile, and I plan to refactor it,
just add some tests to ensure that everything is and keeps working as
intended.
R=mstarzinger@chromium.org
Bug: v8:7758
Change-Id: Ib3814b93b465286d70b5669ed0161eecb9fc925a
Reviewed-on: https://chromium-review.googlesource.com/1059616
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53187}
This makes sure that the {WasmModuleObject} has been allocated before
any debug events are fired. Since {WasmScript} objects reference the
module object, it needs to be allocated earlier by now.
R=ahaas@chromium.org
TEST=debugger/regress/regress-crbug-840288
BUG=chromium:840288
Change-Id: I02783ce126c463ac953eb2192acb65f3a5d420a1
Reviewed-on: https://chromium-review.googlesource.com/1050246
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53084}
In order to get more test coverage (also on ClusterFuzz), stage Liftoff
and tier up behind --future.
R=hablich@chromium.org
CC=titzer@chromium.org
Bug: v8:6600
Change-Id: I718e17957b26f60aa4c002333035f693344806e0
Reviewed-on: https://chromium-review.googlesource.com/1042385
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52987}
This is a reland of a0c57368a9
Original change's description:
> [wasm] Maintain link from Instance to Module.
>
> This moves the link from a {WasmInstanceObject} to its corresponding
> {WasmModuleObject} into the right place and also makes it strong. This
> ensures that an instance always keeps the underlying module alive and
> hence removes the situation of an "orphaned instance".
>
> R=clemensh@chromium.org
>
> Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
> Reviewed-on: https://chromium-review.googlesource.com/1041691
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52942}
Change-Id: I9854400bfc1d22bd258f17118fcb7460cdc3acd5
Reviewed-on: https://chromium-review.googlesource.com/1043786
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52985}
This reverts commit a0c57368a9.
Reason for revert: Speculative revert due to failures with custom
snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/19061
Local bisect also points to this change:
http://shortn/_IhVxU2FKLu
Original change's description:
> [wasm] Maintain link from Instance to Module.
>
> This moves the link from a {WasmInstanceObject} to its corresponding
> {WasmModuleObject} into the right place and also makes it strong. This
> ensures that an instance always keeps the underlying module alive and
> hence removes the situation of an "orphaned instance".
>
> R=clemensh@chromium.org
>
> Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
> Reviewed-on: https://chromium-review.googlesource.com/1041691
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52942}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I1830e6ce14314f06f918a0c428182bfd68354ad9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1041968
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52949}
This moves the link from a {WasmInstanceObject} to its corresponding
{WasmModuleObject} into the right place and also makes it strong. This
ensures that an instance always keeps the underlying module alive and
hence removes the situation of an "orphaned instance".
R=clemensh@chromium.org
Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
Reviewed-on: https://chromium-review.googlesource.com/1041691
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52942}
* If the mutability of the global object doesn't match the module, then
it should throw a LinkError.
* There was a missing `return` when importing a Number as a mutable
global.
* All globals were being exported as immutable.
* Attempting to set the value of an immutable global should throw a
TypeError.
* The length of the setter function should be 1.
Bug: v8:7625
Change-Id: I08d6a428506a18db15eecadf4cbcee89e0658924
Reviewed-on: https://chromium-review.googlesource.com/1031626
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52865}
In the case of an indirect call to an imported function, the target
instance stored in the IFT was actually wrong.
Bug: chromium:834619
Change-Id: Id2ac4158335ecf2b58e1983ce37df852a9ebd1b2
Reviewed-on: https://chromium-review.googlesource.com/1030174
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52831}
The new spec has two arguments, the first is the global descriptor, and
the second is the initial value:
new WebAssembly.Global({type: i32}, 42);
If the initial value argument is omitted, the value is set to 0.
Bug: v8:7625
Change-Id: I679d4b7c49c69ec7ffcdfeb8ae506fa7ab9bba95
Reviewed-on: https://chromium-review.googlesource.com/1028847
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52822}
The WasmInstanceObject stores two new arrays:
- imported_mutable_globals_buffers_: a FixedArray of all the imported
globals' array buffers.
- imported_mutable_globals: a calloc'd array of Addresses pointing to
the mutable global in its array buffer.
When accessing the global, the generated code looks up the address in
imported_mutable_globals to find where to load/store.
Bug: v8:7625
Change-Id: I60844c21a788fce28f346455f10f2283d1c152e9
Reviewed-on: https://chromium-review.googlesource.com/1020602
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52794}
The mutable-globals proposal spec allows importing as Numbers or
WebAssembly.Global values, but always exports as WebAssembly.Global.
Since the value is always boxed, we can also import/export i64 values.
This CL also includes support for export of mutable globals. Since the
underlying ArrayBuffer that stores the global's value is shared between
the module and the WebAssembly.Global object, all that needs to be done
is remove the validation check.
Bug: v8:7625
Change-Id: I24d763e3bc193d229a7cc33b2f2690a473c6f2bc
Reviewed-on: https://chromium-review.googlesource.com/1018406
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52789}
Now that tables and stack frames properly root instances, there is no
longer any need to disallow mutations that could unroot instances
while their code is on the stack.
Bug: v8:7232
Change-Id: I907b9522ac12ad7a67fb4124774713b6b3b40bb7
Reviewed-on: https://chromium-review.googlesource.com/1007004
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52629}
The deadlock should be fixed with https://crrev.com/c/1002174.
This is a reland of 4d1c2907d3
Original change's description:
> Reland "[d8][wasm] Test wasm compilation completion"
>
> This is a reland of ed2605f040
>
> Original change's description:
> > [d8][wasm] Test wasm compilation completion
> >
> > d8 was recently changed to keep running until wasm compilation has
> > completed. This adds a message test to test that.
> >
> > R=ahaas@chromium.org
> >
> > Change-Id: I73af53b6df4ee5f9a6afd26cf2d71a269140465f
> > Reviewed-on: https://chromium-review.googlesource.com/966184
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#52008}
>
> Change-Id: Iadbd5056dfa58da454956c4e89369af8b0455b35
> Reviewed-on: https://chromium-review.googlesource.com/975242
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52154}
Bug: chromium:824681
Change-Id: I4077645bcfcb2320f6573bb779027add36feee3f
Reviewed-on: https://chromium-review.googlesource.com/999632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52505}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
R=mstarzinger@chromium.org
Change-Id: Ia35a3ce91a8f6135767fa764e185cde8bbc889f4
Reviewed-on: https://chromium-review.googlesource.com/997932
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52436}
This reverts commit 57bf0bfefb.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Merge the WasmContext into WasmInstanceObject
>
> This change makes lifetime management of WasmCode much simpler.
> By using the WasmInstanceObject as the context for WASM code execution,
> including the pointer to the memory base and indirect function tables,
> this keeps the instance alive when WASM code is on the stack, since
> the instance object is passed as a parameter and spilled onto the stack.
> This is in preparation of sharing the code between instances and
> isolates.
>
> Bug: v8:7424
>
> Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
> Reviewed-on: https://chromium-review.googlesource.com/958520
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52361}
TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7424
Reviewed-on: https://chromium-review.googlesource.com/995418
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52364}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
Reviewed-on: https://chromium-review.googlesource.com/958520
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52361}
This change implements the WebAssembly.Global object and constructor,
but none of the accessors or functions.
There is a new flag to enable this: --experimental-wasm-mut-global.
Change-Id: Ifeb270d57392d7ca0900c80c0038932c96ee8b61
Reviewed-on: https://chromium-review.googlesource.com/989296
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52335}
For the wasm2js wrappers we have an optimization to call a JavaScript
function directly if the signature of the JavaScript function matches
the signature of the WebAssembly import. However, we are not supposed
to do this optimization if the imported function is a constructor,
because constructors can only be called with `new`. With this CL we
do not apply this optimization when the imported function is a
constructor.
R=titzer@chromium.org
Bug: chromium:824859
Change-Id: I1722367bd865d0b129eadf7d4849182410447179
Reviewed-on: https://chromium-review.googlesource.com/985974
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52296}
This is a reland of ed2605f040
Original change's description:
> [d8][wasm] Test wasm compilation completion
>
> d8 was recently changed to keep running until wasm compilation has
> completed. This adds a message test to test that.
>
> R=ahaas@chromium.org
>
> Change-Id: I73af53b6df4ee5f9a6afd26cf2d71a269140465f
> Reviewed-on: https://chromium-review.googlesource.com/966184
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52008}
Change-Id: Iadbd5056dfa58da454956c4e89369af8b0455b35
Reviewed-on: https://chromium-review.googlesource.com/975242
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52154}
This reverts commit ed2605f040.
Reason for revert: Test flakes.
Original change's description:
> [d8][wasm] Test wasm compilation completion
>
> d8 was recently changed to keep running until wasm compilation has
> completed. This adds a message test to test that.
>
> R=ahaas@chromium.org
>
> Change-Id: I73af53b6df4ee5f9a6afd26cf2d71a269140465f
> Reviewed-on: https://chromium-review.googlesource.com/966184
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52008}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: If1e015bd346a71df1da8effe92882c37a00d1e62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/968521
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52023}
d8 was recently changed to keep running until wasm compilation has
completed. This adds a message test to test that.
R=ahaas@chromium.org
Change-Id: I73af53b6df4ee5f9a6afd26cf2d71a269140465f
Reviewed-on: https://chromium-review.googlesource.com/966184
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52008}
The flag lets d8 wait for async compilation of WebAssembly to finish
before d8 shuts down.
R=clemensh@chromium.org
CC=kimanh@google.com
Change-Id: I4cf59a1f35cc5a0ecaf769d2745df5e2e14eb509
Reviewed-on: https://chromium-review.googlesource.com/966031
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51999}
According to the spec, exported wasm functions should not have a
[[Construct]] method, hence they don't have a prototype.
R=bmeurer@chromium.org
CC=titzer@chromium.org
Bug: v8:7503
Change-Id: I9e142d65a80c0ef6dbd743421771f194c2d50614
Reviewed-on: https://chromium-review.googlesource.com/939782
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51622}
There is a clear mistake of using kWasmF64 instead of kWasmF32.
R=ahaas@chromium.org
Change-Id: I638d568b3736fdb8417f17bcd04d17268a45b965
Reviewed-on: https://chromium-review.googlesource.com/939178
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51595}
When calling a function through a function table, check whether the
instance of the called function differs from the current instance, and
in that case call the other function via a c-wasm-entry instead of
interpreting it.
The c-wasm-entry needs to pass the wasm context, so this CL changes
this to receive the wasm context as parameter instead of embedding the
context of the calling instance.
R=titzer@chromium.org
Bug: chromium:814562, v8:7400
Change-Id: Iea93f270542169f8aac4f8c81aacec559c716368
Reviewed-on: https://chromium-review.googlesource.com/930966
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51485}
AddCode and AddOwnedCode (from NativeModule), as well as the WasmCode
constructor are using a default value (false) for determining whether
the code is liftoff-compiled or not. This CL removes the default
value and requires each call to these functions/constructors to explicitly
set the value.
Change-Id: Icd4187d1710c774826c9134078ec65845bc98dd7
Reviewed-on: https://chromium-review.googlesource.com/928921
Commit-Queue: Kim-Anh Tran <kimanh@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51475}
They were disabled for some reason, but they are working, so reenable
them.
R=titzer@chromium.org
Change-Id: I24cab05d01060b9eae3d6191a978cdb04daf626b
Reviewed-on: https://chromium-review.googlesource.com/928648
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51440}
This CL changes the WASM implementation to access indirect function
tables through the WasmContext, whereas previously indirect function
tables and their sizes were constants that were inlined into compiled
into code, requiring code patching. This is a necessary step for sharing
code between instances and eventually, isolates.
R=clemensh@chromium.org,mstarzinger@chromium.org
Bug: v8:7424
Change-Id: Ida4138ed92729730dfbc0a81a84d8484b233d808
Reviewed-on: https://chromium-review.googlesource.com/895683
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51427}
Tbr: jarin@chromium.org
Change-Id: I17477e2c82398b228a366a3d1fd8eb521dd51eae
Reviewed-on: https://chromium-review.googlesource.com/922270
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51317}
I fixed some spec tests since the last update, so we can turn them on
again. The problem was in the spec test itself and not in V8.
R=titzer@chromium.org
Change-Id: Id2755138293d22d49e0393b884df797a1134b6f9
Reviewed-on: https://chromium-review.googlesource.com/919041
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51290}
According to the spec, if an imported function gets exported, the
exported function has to be identical to to imported function.
With this CL we initialize the list of potential js_wrappers_ with all
wasm function we imported. Therefore no new wrappers are generated for
these functions.
R=clemensh@chromium.org
Bug: v8:7364
Change-Id: Ibcd47d8fcc4c2fb5740d57ea547fbd01c2a4e80a
Reviewed-on: https://chromium-review.googlesource.com/901626
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51244}
The test required a special runtime function, which did not work in
general but only in the context of that one test. After an offline
discussion we decided that what the test is testing is not worth a
runtime function, since we would also see in other tests if something
goes wrong.
R=clemensh@chromium.org
Bug: v8:7403
Change-Id: I129a189a9df299d409a4a555eae28783e47b97d1
Reviewed-on: https://chromium-review.googlesource.com/901284
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51095}
Especially "invalid function" and "invalid type" could contain much
more information.
Drive-by: Remove unused WasmTrapInvalidIndex.
R=ahaas@chromium.org
Change-Id: I7fd72c095eaad94e3e2d9bfe6ab4a9ce0bb4798b
Reviewed-on: https://chromium-review.googlesource.com/897526
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51059}
In addition I added some comments in the update script which describes
steps which have to be takes the first time you run the script on a
new machine.
R=titzer@chromium.org
Change-Id: Ib360e6fcdcb63eaf225f398eff60041b48f86b62
Reviewed-on: https://chromium-review.googlesource.com/883344
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50863}
This fixes a corner-case where deserialization of a module containing
multiple exported functions of the same signature forgot to properly
unprotect the code-space. Test coverage has been added.
R=clemensh@chromium.org
TEST=mjsunit/wasm/compiled-module-serialization
BUG=chromium:804767
Change-Id: I0082303db19bcc14c4de30f29d604665e281d79d
Reviewed-on: https://chromium-review.googlesource.com/880844
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50799}
The WebAssembly JS API specification [1] covers the JS-visible side-effects
of executing a grow_memory operation and states that a successful
grow operation should always detach any prior array buffer.
[1] https://github.com/WebAssembly/spec/blob/master/document/js-api/index.bsR=mstarzinger@chromium.org,gdeepti@chromium.org
Bug:
Change-Id: Ib9232e01209ba546c0bba1c9408c92da60ff6d92
Reviewed-on: https://chromium-review.googlesource.com/860011
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50627}
This adds support for direct calls in Liftoff.
Drive-by: Fix / extend two tests for calls which were helpful for
developing this CL.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I20a98d9dd330da9a020c8c9b5c10b04e94af684d
Reviewed-on: https://chromium-review.googlesource.com/847579
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50427}
This is a reland of 9c79b37aa7
Original change's description:
> [wasm] use allocation tracker to track reserved address space
>
> This is a step towards falling back on bounds checks when there are too many
> guarded Wasm memories.
>
> Bug: v8:7143
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I01916cbdd5ddb08fe1d946ab83b801f37a8fe1c6
> Reviewed-on: https://chromium-review.googlesource.com/832944
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50390}
Bug: v8:7143
Change-Id: Iaf0d22d300a3f2da22649552a17162dcf7bc608b
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/853142
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50418}
The tests generated by --wasm-fuzzer-gen-test did not encode the locals
of functions yet. This CL fixes that.
A bit of care has to be taken to ensure that the locals are generated
in exactly the same order as in the module generated by the fuzzer.
This requires calling {addLocals} several times.
R=ahaas@chromium.org
Change-Id: I95237b0baef0731b6c164fddc8f12fa6f478e220
Reviewed-on: https://chromium-review.googlesource.com/848832
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50402}
This reverts commit 9c79b37aa7.
Reason for revert: breaks TSAN
https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux64_TSAN%2F18959%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Finstance-gc%2F0
Original change's description:
> [wasm] use allocation tracker to track reserved address space
>
> This is a step towards falling back on bounds checks when there are too many
> guarded Wasm memories.
>
> Bug: v8:7143
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I01916cbdd5ddb08fe1d946ab83b801f37a8fe1c6
> Reviewed-on: https://chromium-review.googlesource.com/832944
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50390}
TBR=bbudge@chromium.org,gdeepti@chromium.org,eholk@chromium.org,eholk@google.com
Change-Id: I207b9466377ba50be17794e71407b0ebc8eb88e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7143
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/853140
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50392}
This is a step towards falling back on bounds checks when there are too many
guarded Wasm memories.
Bug: v8:7143
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I01916cbdd5ddb08fe1d946ab83b801f37a8fe1c6
Reviewed-on: https://chromium-review.googlesource.com/832944
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50390}
When shared memory is defined in the module bytes, and not imported/exported
underlying memory should be a SharedArrayBuffer. This was missing in the
allocate flow during instantiation. Fixed to use a SharedArrayBuffer.
BUG=v8:6532
Change-Id: Ic62ed3fd578a0e03124ee40b273e6a4ea474bba4
Reviewed-on: https://chromium-review.googlesource.com/835348
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50255}
Make sure that a continue still executed the increment part of a for
loop by adding another nested block for the body, which is the break
target for a continue in the body. The increment code lives outside
this block, in the original loop.
R=bradnelson@chromium.orgCC=mstarzinger@chromium.org
Bug: chromium:788916
Change-Id: I178b874ffac16d9237a0f4da097d2742bd93335a
Reviewed-on: https://chromium-review.googlesource.com/832447
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50169}
- Implement RunMicrotasks in CSA to prevent a potentially large number
of jumps between C++ and JS code while consuming te queue. Appears to
provide a ~60% speedup in microtask-heavy code, which from limited
testing appears to scale linearly.
The code-stub microtask pump bails out to the old C++ microtask pump
if it encounters a CallHandlerInfo microtask, and remains in C++ for
the remainder of the queue (returning to the JS/stub implementation
after the bailed out queue is exhausted).
- Add a variation of JSEntryStub which enters the new RunMicrotasks code
stub.
- Add a new RunMicrotasks helper to Execution, which uses the
RunMicrotasks entry stub.
Bug:
Change-Id: I4667d4dd633d24455ea5d7cef239da0af1a7365e
Reviewed-on: https://chromium-review.googlesource.com/650486
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49842}
In order to test that we don't repeatedly go through the
WasmCompileLazy runtime function, add a flag to the
LazyCompilationOrchestrator to "freeze" it, i.e. disallow any further
lazy compilation.
In tests, use this flag to first call a method, then freeze lazy
compilation, then call the method again to assert that no further lazy
compilation is triggered.
This test currently fails with --wasm-jit-to-native, so disable it for
that variant.
R=titzer@chromium.orgCC=mtrofin@chromium.org
Bug: v8:7140, chromium:788441, v8:5991
Change-Id: I18a40d302c24041740d8a54351d06ed968f4beec
Reviewed-on: https://chromium-review.googlesource.com/796430
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49734}
When exporting an imported wasm function, we generate a js-to-wasm
wrapper which calls the wasm-to-wasm wrapper (which then tail-calls
the WasmCompileLazy stub).
This wasm-to-wasm wrapper also needs to be patched.
R=titzer@chromium.org
Bug: chromium:788441, v8:5991
Change-Id: Ibf27618a0511851cb55714b720fe7299a21c2959
Reviewed-on: https://chromium-review.googlesource.com/795990
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49715}
Within SanitizeImports it is possible that JavaScript code gets executed
therefore we have to open the CodeSpaceMemoryModificationScope after
SanitizeImports.
R=clemensh@chromium.org
Bug: chromium:788469
Change-Id: Ide9bbd4ee4613b28380979d4a6c66d26e6a9406f
Reviewed-on: https://chromium-review.googlesource.com/789936
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49635}
The existing access to the signatures is plain wrong. This CL fixes
this.
Note that cross-instance indirect calls are only enabled since a few
days (https://crrev.com/c/778159), which is why this bug was not
detected before.
R=titzer@chromium.org
Bug: chromium:787910
Change-Id: Iaac4d1d85840c921eb8554c5094933ec8d987802
Reviewed-on: https://chromium-review.googlesource.com/787312
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49607}
This is a reland of 712fa67554.
Original change's description:
> [test] Add Liftoff variant
>
> Add a variant for testing the current state of the Liftoff
> implementation.
> This variant will only run on a subset of the bots, just like the
> --future variant.
>
> R=machenbach@chromium.org, hablich@chromium.org
>
> Bug: v8:7088, v8:6600
> Change-Id: If49fad3a8ed579356504b821a787326754f24e78
> Reviewed-on: https://chromium-review.googlesource.com/779420
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49504}
TBR=machenbach@chromium.orgCC=hablich@chromium.org
Bug: v8:7088, v8:6600
Change-Id: Ieb20020f07c70acaa64bb421763a41aa163a261b
Reviewed-on: https://chromium-review.googlesource.com/781499
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49531}
This is a reland of 236298acbf.
Original change's description:
> [wasm] Unify deoptimization data
>
> Add methods to add deoptimization data and use them from all the places
> where we currently add them manually. Also add them to wasm-to-wasm
> wrappers compiled on table set, which was missing before, leading to
> the referenced bug.
>
> R=ahaas@chromium.org
>
> Bug: chromium:779292
> Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
> Reviewed-on: https://chromium-review.googlesource.com/774838
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49452}
Bug: chromium:779292
Change-Id: I8219305fc894c50904db57e51245733f6613dcd3
Reviewed-on: https://chromium-review.googlesource.com/778159
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49508}
This reverts commit 236298acbf.
Reason for revert: suspected cause of failures on GC stress bots:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/16341https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/16269
Original change's description:
> [wasm] Unify deoptimization data
>
> Add methods to add deoptimization data and use them from all the places
> where we currently add them manually. Also add them to wasm-to-wasm
> wrappers compiled on table set, which was missing before, leading to
> the referenced bug.
>
> Drive-by: Disable non-applicable MaybeHandle constructors to allow
> overloading functions with different Handle types.
>
> R=ahaas@chromium.org
>
> Bug: chromium:779292
> Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
> Reviewed-on: https://chromium-review.googlesource.com/774838
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49452}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: I02fb49d2ece8e04ac5fb26f618bfe6fb2f133d06
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:779292
Reviewed-on: https://chromium-review.googlesource.com/777079
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49455}
Add methods to add deoptimization data and use them from all the places
where we currently add them manually. Also add them to wasm-to-wasm
wrappers compiled on table set, which was missing before, leading to
the referenced bug.
Drive-by: Disable non-applicable MaybeHandle constructors to allow
overloading functions with different Handle types.
R=ahaas@chromium.org
Bug: chromium:779292
Change-Id: Ib9132d9faeb1092c46e22dd8196d201ce5c0942f
Reviewed-on: https://chromium-review.googlesource.com/774838
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49452}
This is a reland of 77b0baa649.
Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
>
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
>
> R=ahaas@chromium.org
>
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}
Bug: chromium:779569, v8:5991
Change-Id: I4818e933467bd5a040f1514b8fc18db219a092c7
Reviewed-on: https://chromium-review.googlesource.com/774538
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49426}
This reverts commit 77b0baa649.
Reason for revert: Breaks on win64 bot: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Win64_-_debug%2F20172%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Flazy-compilation%2F0
Original change's description:
> [wasm] Fix importing wasm-lazy-compile stubs
>
> If two modules use lazy compilation, and one imports a function of
> another, we are unwrapping the js-to-wasm wrapper of the export. This
> was failing so far, because during unwrapping we did not find the wasm
> code.
> This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
> code".
>
> R=ahaas@chromium.org
>
> Bug: chromium:779569, v8:5991
> Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
> Reviewed-on: https://chromium-review.googlesource.com/771672
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49405}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: If5ab7b9de95ef662a65a6a5b919fa1f13aa492cd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:779569, v8:5991
Reviewed-on: https://chromium-review.googlesource.com/774518
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49409}
If two modules use lazy compilation, and one imports a function of
another, we are unwrapping the js-to-wasm wrapper of the export. This
was failing so far, because during unwrapping we did not find the wasm
code.
This CL fixes this by also recognizing WasmCompileLazy stubs as "wasm
code".
R=ahaas@chromium.org
Bug: chromium:779569, v8:5991
Change-Id: If2260c3721e3746a7635b9d0182fd520df2fb773
Reviewed-on: https://chromium-review.googlesource.com/771672
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49405}
When calling the CWasmEntry in order to call from the interpreter to a
wasm function, the given buffer must hold the arguments, and must also
have enough space to hold the return values. We were missing the second
part, hence we failed when there are no parameters, but a return.
R=ahaas@chromium.org
Bug: chromium:784125
Change-Id: I08d417cae60eea64fda8a72e898dbed9f3e88148
Reviewed-on: https://chromium-review.googlesource.com/771633
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49402}
Like CSP flag 'unsafe-eval', which communicates if both JS source
files and WASM binary files may be compiled, this CL adds a similar
flag for the compilation of WASM binary files.
That is, a WASM binary file will be compiled only if the new flag is
defined, or the flag for 'unsafe-eval' allows it. These flags are
implemented as callback functions on the isolate. The callbacks get a
(CSP) context, and a string, and returns the corresponding value of
the flag.
Both callbacks are initialized with the nullptr, and is used to
communicate that no CSP policy is defined. This allows this concept to
work, independent of it running in Chrome.
It also does a small clean up in api.cc to use macro CALLER_SETTERS,
instead of explicit code when appropriate.
Bug: v8:7041
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idb3356574ae2a298057e6b7bccbd3492831952ae
Reviewed-on: https://chromium-review.googlesource.com/759162
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49243}
Because this test uses heap verification, it is quite slow. Split it
into 4 smaller tests to avoid test timeout and allow them to be run
in parallel.
R=ahaas@chromium.org
Bug:
Change-Id: Ie4ac841d1d8215019bb5cfcc335daea6b10ab789
Reviewed-on: https://chromium-review.googlesource.com/738146
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48998}
This adds two tests to verify that the --liftoff flag has the indented
effect, and that Liftoff compilation is off by default.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ie7e13184b5068f572b78dbdf7abbcded6d859fc5
Reviewed-on: https://chromium-review.googlesource.com/733561
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48995}
There is no need to test each operation on each single memory location.
R=titzer@chromium.org, binji@chromium.org
Bug: v8:6994
Change-Id: Ib401fa1dd4db2e1b9c7ee0b48bb0c1cc9e3f9139
Reviewed-on: https://chromium-review.googlesource.com/735149
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48921}
We were already handling the case that a called import throws, but if
it returned an error which is not convertible to a number, we failed
with a CHECK error.
This CL fixes this.
R=titzer@chromium.org
Bug: chromium:771970
Change-Id: I6c9983459109d49c43304610b696d49de986a250
Reviewed-on: https://chromium-review.googlesource.com/735354
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48912}
The wasm memory deserialization didn't properly increment the object id, so
wouldn't work properly if the memory object (or its contained
SharedArrayBuffer) where included multiple times in the object.
Bug: v8:6895
Change-Id: I5c4c25bad2ec6152883c5a7321038aba1950480a
Reviewed-on: https://chromium-review.googlesource.com/721630
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48767}
TurboFan expects the offset input of a Load or Store node to be a
pointer-size input, i.e. an int32 input on 32-bit platforms, and int64
on 64-bit platforms. In WebAssembly we always provided 32-bit offset
though, which caused problems when the high word of the register which
contained the offset was not empty.
With this CL we change the offset input to int64 on 64-bit platforms.
In addition we also change the type of the memory_size_ node to int64,
so that that we do not have to adjust the type of the memory size at
every memory load.
This CL will cause performance regressions but is necessary for
correctness and to avoid crashes.
R=titzer@chromium.org
Bug: chromium:766666
Change-Id: I5301e108d05e125258d2a06d500c1b75e91697b8
Reviewed-on: https://chromium-review.googlesource.com/723379
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48689}
This CL removes the code specialization for WASM functions that access
globals. Previously, we were embedding the start address of the globals
memory (globals_start) as a constant in the code, which required
patching for every instance. We now put this base in to the WasmContext,
which is available as a parameter to every WasmFunction.
R=ahaas@chromium.org,
CC=mtrofin@chromium.org
Bug:
Change-Id: I04bb739e898cc5a3b7dd081cc166483022d113fd
Reviewed-on: https://chromium-review.googlesource.com/712595
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48581}
This patch introduces assertPromiseFulfills and assertPromiseFulfills as
a replacement for assertPromiseResult because it’s more JavaScript-y.
BUG=v8:6921
R=ahaas@chromium.org
Also-By: ahaas@chromium.org
Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31
Reviewed-on: https://chromium-review.googlesource.com/718746
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48578}
This flag describes that the memory defined in a wasm module has a
maximum size. Therefore I think kHasMaximumFlag is more appropriate.
R=titzer@chromium.org
Bug: v8:6921
Change-Id: Ie794d670f74e7f1f9a42822e2f774da85aaaaa4b
Reviewed-on: https://chromium-review.googlesource.com/718198
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48517}
Missing arguments are identical to undefined, and are converted to the
integer 0 by ECMAScript {ToInteger()}.
Add more tests, and enable previously disabled tests.
There is a follow-up refactoring here: https://crrev.com/c/704586R=titzer@chromium.org, mstarzinger@chromium.org
Change-Id: I89cc259aaf5975ec2f6f51ff002e7d1b32adba5e
Reviewed-on: https://chromium-review.googlesource.com/704658
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48373}
When atomic operations are used in loops, return the correct opcode length
for loop assignment.
Bug=v8:6842,v8:6532
Change-Id: I306db704d8a0baa5d98c05702360e6dfae11cbfa
Reviewed-on: https://chromium-review.googlesource.com/699561
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48273}
The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.
This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.
The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution. The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.
This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).
R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org
Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
There was an issue with passing float32 parameters, if the value was
spilled on the stack and passed as stack parameter.
First, we sometimes reduced the stack pointer by 8 bytes instead of 4,
and second, there was a mismatch between movsd and movss.
R=titzer@chromium.org
Bug: chromium:718858
Change-Id: Ia884df369ddd95adeff3733f9715f589996f0b65
Also-By: ahaas@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/684738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48181}
This is a second attempt at landing CL 644866 which was reverted by
CL 667019.
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
A JS typed (uint_16) array is used to hold the thrown values. This
allows all WASM types to be stored (i32, i64, f32, and f64) as well as
be inspected in JS.
The previous CL was reverted because the WASM compiler made calls to
run time functions with tagged objects, which must not be done. To fix
this, all run time calls use the thread-level isolate to hold the
exception being processed.
Bug: v8:6577
Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
Reviewed-on: https://chromium-review.googlesource.com/677056
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48148}
Memory instantiate on initialize should always patch memory
references. If memory references are not patched for no initial
memory, on subsequent calls to grow_memory in wasm functions for
instances that share a module, the references will be patched
without resetting cloned compiled values to their correct initial
values.
BUG=chromium:763439
Change-Id: I666439332379b02aa344e99d61ef3dc88ab86cc8
Reviewed-on: https://chromium-review.googlesource.com/674707
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48097}
This is primarily to aid in testing the Wasm out of bounds trap handler. We
keep track of how many faults have been recovered by the Wasm trap handler. This
count is exposed to JavaScript through a testing-only runtime function. This
allows tests to verify whether the trap handler is actually running.
Bug: v8:5277
Change-Id: Ie8037a36d84eb08166c6e40c7225d912683d5786
Reviewed-on: https://chromium-review.googlesource.com/665968
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48076}
This reverts commit 7b5a40222e.
Reason for revert: GC stress-test failures exposed by 7742e534a8https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15110/steps/Mjsunit/logs/exceptions
Original change's description:
> Add capability of throwing values in WASM
>
> Extends the current implementation of WASM exceptions to be able to
> throw exceptions with values (not just tags).
>
> An JS typed array (uint_16) is used to hold thrown values, so that the
> thrown values can be inspected in JS.
>
> Bug: v8:6577
> Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
> Reviewed-on: https://chromium-review.googlesource.com/633866
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48001}
TBR=bbudge@chromium.org,mtrofin@chromium.org,eholk@chromium.org,clemensh@chromium.org,kschimpf@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6577
Change-Id: I8f545183c2d2abb1bf4a0b3ee23379f3754ffd55
Reviewed-on: https://chromium-review.googlesource.com/667019
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48050}
In this CL I implement streaming compilation for WebAssembly,
as described in the design doc I have sent out already.
In this implementation the decoding of sections other than the
code section is done immediately on the foreground thread.
Eventually all decoding should happen in the background. I
think it is acceptable to do the decoding on the foreground
thread for now because I have finished it already, and
decoding in the background would add even more complexity to
this CL.
Bug:v8:6785
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I285e1e5e1a5a243113c92571b25ee9bae551d0ed
Reviewed-on: https://chromium-review.googlesource.com/631721
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48022}
- Validate that atomic ops can only be called when shared memory is declared
- Throw Compile/Link erros on mismatch between declared, imported memory
- Test harness helpers for setting shared memory, tests
BUG=v8:6532
R=binji@chromium.org, bradnelson@chromium.org
Change-Id: I43fe3d04bb7e3e0a2cecca0528578f98844d2608
Reviewed-on: https://chromium-review.googlesource.com/665379
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48019}
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.
Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
The wasm valiation incorrectly allowed simd locals, even without the
experimental flag turned on. This was not noted in the generated code
because simd opcodes were forbidden, but the interpreter could not
handle these locals.
R=clemensh@chromium.org
Bug: chromium:763697
Change-Id: I11d924ac21e50bce81d0504c2c7b252105a89f80
Reviewed-on: https://chromium-review.googlesource.com/660117
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47946}
Use int instead of byte to store the source position when computing a
location based on the stack trace stored in an error object.
Also add tests, since this code path was not covered before (not even
for small position where it would have succeeded).
Also, add some comments about which positions are 0-based and 1-based.
R=titzer@chromium.org
Change-Id: I313dcd6c47b77093ced9bb687415715d04eafb97
Reviewed-on: https://chromium-review.googlesource.com/645527
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47739}
This CL introduces two tests to verify that the correct memory is
accessed when a wasm module invokes an wasm function imported from a
second module that accesses its (i.e., second module's) memory.
The first test verifies that the second module's memory is accessed in
case the first module does not have memory. In the second test, both the
modules have memory.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I75c3a5335583a91af0e7e4179c482142165b1c01
Reviewed-on: https://chromium-review.googlesource.com/637837
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47702}
This reimplements functionality that was present before the decoder
refactoring. It's implemented a bit differently though by generating
the code for re-throwing an uncaught exception earlier (when generating
code for the catch).
R=titzer@chromium.org, kschimpf@chromium.org
Bug: v8:6600
Change-Id: Ie2f11837851c0602ab31506fa63475fc2d0b5047
Reviewed-on: https://chromium-review.googlesource.com/641550
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47687}
This is a reland of 6b4dc039a6
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org
Bug: v8:6600
Change-Id: Idd867c5a1917437de5b6e3de5917cc1c9f194489
Reviewed-on: https://chromium-review.googlesource.com/640591
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47678}
This CL introduces 4 test that verify that the effects of a grow_memory
instruction executed in a function invoked inside a loop are visible
also when the loop is over. This is needed because the
AnalyzeLoopAssignment method in function-body-decoder.cc is creating Phi
nodes only for variables assigned inside the loop. The test cases
introduced by this CL verify that the mem_size and mem_start variables
are always correct.
The tests verify the output of the current_memory instruction and the
result of loading a variable stored in the grown memory inside the
loop in the following cases:
* the memory is grown in a directly called function inside a loop;
* the memory is grown in an indirectly called function inside a loop.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I2992bf4086b5eac9580c87e2e0ca06364b99714c
Reviewed-on: https://chromium-review.googlesource.com/637911
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47674}
This reverts commit 6b4dc039a6.
Reason for revert: Mips build failure: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/11749
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: I76a50e355f0390cc53a2da4ceedd8830ca20a9c6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600
Reviewed-on: https://chromium-review.googlesource.com/640870
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47672}
This refactoring separates graph building from wasm decoding. The
WasmGraphBuilder is just a consumer of the decoded information.
Decoding without any consumer (i.e. just validation) gets 16% faster by
this refactoring, because no TFNode* have to be stored in the value
stack, and all dynamic tests to determine whether the graph should be
build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
92.2 +- 3.1 ms).
This new design will allow us to also attach other consumers, e.g. a
new baseline compiler.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
Reviewed-on: https://chromium-review.googlesource.com/571010
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47671}
Get the old table size after converting integer of 'delta' argument.
Converting integer of the argument can execute another javascript code,
and the code can trigger mismatching between table sizes of instance and
table object, which causes redundant memory allocation.
http://webassembly.org/docs/js/#webassemblytableprototypegrow
Bug: chromium:752423
Change-Id: If9a576d20625d0c39342ea5de114e9fc9f230125
Reviewed-on: https://chromium-review.googlesource.com/627248
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47641}
Compile the module created in trap-location.js with both synchronous and
asynchronous compilation. Thereby I can reuse the test for streaming
compilation later.
R=clemensh@chromium.org
Change-Id: Id2e0c70886ddd1b11d51f614d02757099541aedd
Reviewed-on: https://chromium-review.googlesource.com/635165
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47600}
This CL introduces 4 tests that verify that the effects of a grow_memory
instruction executed inside a loop are visible also when the loop is over.
The tests verify the output of the current_memory instruction and the
result of loading a variable stored in the grown memory inside the
loop in the following cases:
* the memory is grown inside the loop (no memory operation outside);
* the memory is grown both inside and outside the loop;
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I1670aa4d8274f6c54dced98cced7b51534552c36
Reviewed-on: https://chromium-review.googlesource.com/619207
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47466}
This reverts commit af37f6b970.
Reason for revert: Reverted dependency fixed.
Original change's description:
> Revert "[wasm] Reference indirect tables as addresses of global handles"
>
> This reverts commit 186099d49f.
>
> Reason for revert: Need to revert:
> https://chromium-review.googlesource.com/c/613880
>
> Original change's description:
> > [wasm] Reference indirect tables as addresses of global handles
> >
> > This sets us up for getting the wasm code generation off the GC heap.
> > We reference tables as global handles, which have a stable address. This
> > requires an extra instruction when attempting to make an indirect call,
> > per table (i.e. one for the signature table and one for the function
> > table).
> >
> > Bug:
> > Change-Id: I83743ba0f1dfdeba9aee5d27232f8823981288f8
> > Reviewed-on: https://chromium-review.googlesource.com/612322
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#47444}
>
> TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org
>
> Change-Id: Ic3dff87410a51a2072ddc16cfc83a230526d4c56
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/622568
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47450}
TBR=bradnelson@chromium.org,machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org
Change-Id: I3dc5dc8be26b5462703edac954cbedbb8f504c1e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/622035
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47455}
This reverts commit e79d4f06fd.
Reason for revert: Fixed compile error
Original change's description:
> Revert "[wasm] Move the ModuleEnv to compiler and make it immutable."
>
> This reverts commit d04660db3f.
>
> Reason for revert: Suspect for blocking the roll:
> https://chromium-review.googlesource.com/c/621191
>
> See:
> https://build.chromium.org/p/tryserver.chromium.win/builders/win_optional_gpu_tests_rel/builds/13583
>
> Original change's description:
> > [wasm] Move the ModuleEnv to compiler and make it immutable.
> >
> > This CL (finally) makes the contract between the compiler and the module
> > environment clear. In order to compile a function, the caller must provide
> > an instance of the compiler::ModuleEnv struct, which contains references
> > to code, function and signature tables, memory start, etc.
> >
> > R=mtrofin@chromium.org,ahaas@chromium.org
> >
> > Bug:
> > Change-Id: I68e44d5da2c5ad44dad402029c2e57f2d5d25b4f
> > Reviewed-on: https://chromium-review.googlesource.com/613880
> > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#47418}
>
> TBR=titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: I60a369a43121720fbb13ea6c2ec6ca948d60a20b
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/622547
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47451}
TBR=machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: Ie0efa6204c41b2cb672586a7ac0a622ca13ce5fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/622033
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47453}
This CL introduces 8 tests that verify that the effects of a grow_memory
instruction executed inside a conditional branch are visible also when
the branch is merged.
The tests verify the output of the current_memory instruction and the
result of loading a variable stored in the grown memory inside the
branch in the following cases:
* the memory is grown inside the if branch (with no else branch);
* the memory is grown inside the if branch (when an else branch exists);
* the memory is grown inside the else branch;
* the memory is grown by different amount of pages inside both the if
and else branches.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I8127ebdf959eed5b7b5ca5aa6033a7ea41465f32
Reviewed-on: https://chromium-review.googlesource.com/617222
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47452}
This reverts commit d04660db3f.
Reason for revert: Suspect for blocking the roll:
https://chromium-review.googlesource.com/c/621191
See:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_optional_gpu_tests_rel/builds/13583
Original change's description:
> [wasm] Move the ModuleEnv to compiler and make it immutable.
>
> This CL (finally) makes the contract between the compiler and the module
> environment clear. In order to compile a function, the caller must provide
> an instance of the compiler::ModuleEnv struct, which contains references
> to code, function and signature tables, memory start, etc.
>
> R=mtrofin@chromium.org,ahaas@chromium.org
>
> Bug:
> Change-Id: I68e44d5da2c5ad44dad402029c2e57f2d5d25b4f
> Reviewed-on: https://chromium-review.googlesource.com/613880
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47418}
TBR=titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: I60a369a43121720fbb13ea6c2ec6ca948d60a20b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/622547
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47451}
This reverts commit 186099d49f.
Reason for revert: Need to revert:
https://chromium-review.googlesource.com/c/613880
Original change's description:
> [wasm] Reference indirect tables as addresses of global handles
>
> This sets us up for getting the wasm code generation off the GC heap.
> We reference tables as global handles, which have a stable address. This
> requires an extra instruction when attempting to make an indirect call,
> per table (i.e. one for the signature table and one for the function
> table).
>
> Bug:
> Change-Id: I83743ba0f1dfdeba9aee5d27232f8823981288f8
> Reviewed-on: https://chromium-review.googlesource.com/612322
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47444}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org
Change-Id: Ic3dff87410a51a2072ddc16cfc83a230526d4c56
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/622568
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47450}
This sets us up for getting the wasm code generation off the GC heap.
We reference tables as global handles, which have a stable address. This
requires an extra instruction when attempting to make an indirect call,
per table (i.e. one for the signature table and one for the function
table).
Bug:
Change-Id: I83743ba0f1dfdeba9aee5d27232f8823981288f8
Reviewed-on: https://chromium-review.googlesource.com/612322
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47444}
This CL (finally) makes the contract between the compiler and the module
environment clear. In order to compile a function, the caller must provide
an instance of the compiler::ModuleEnv struct, which contains references
to code, function and signature tables, memory start, etc.
R=mtrofin@chromium.org,ahaas@chromium.org
Bug:
Change-Id: I68e44d5da2c5ad44dad402029c2e57f2d5d25b4f
Reviewed-on: https://chromium-review.googlesource.com/613880
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47418}
This CL introduces 6 tests that verify that the effects of a grow_memory
instruction executed inside a function are visible also from the caller of
the function.
The tests verify that:
* the current_memory instruction returns the correct value after
returning from a function that grew memory;
* accessing a memory page that has been created inside a function does
not trap in the caller;
* when a function grows the memory and then store something in the grown
memory, the caller always reads from the grown memory. This checks that
the memory start address gets updated in the caller (the memory buffer
could in fact be relocated by the grow_memory instruction).
These tests are implemented for direct and indirect function calls.
R=ahaas@chromium.org,clemensh@chromium.org
Change-Id: Iac8db0fa7a6dd6f530e090af5423fc165d87e863
Reviewed-on: https://chromium-review.googlesource.com/616150
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47398}
The WASM spec maximum memory size is higher than internal V8 maximum object
size. When a memory object grows above this limit (and only in that case), we
should signal an error.
This worked for not-exported memory; however when growing exported memory, the
code was comparing the V8 memory limit with the maximum number of pages defined
in the module, instead of the current number of pages + the number of new
required pages. This lead to signaling errors even when growing exported memory
below the V8 limit if the maximum number of pages specified in the module was
higher than the V8 limit.
GrowMemoryBuffer already checks that we do not grow a memory buffer past the
maximum size specified as parameter, so we can pass it the minimum between the
the V8 limit and the maximum number of pages specified in the module.
This CL introduces a test in test/mjsunit/wasm/import-memory.js that triggers
the problematic path and a patch to fix it.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I5a8da420418b394d61e1ba3cdf4408c3c09e61b6
Reviewed-on: https://chromium-review.googlesource.com/600217
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47395}
Tests were monolithic, with large loops, and slow on ARM64. Refactor to
small tests so they can be sharded better, reduce page size to 1 to
keep the loops small.
BUG=v8:6532
Change-Id: I712551564d4a70fc12acdf114922feb614aeb271
Reviewed-on: https://chromium-review.googlesource.com/611614
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47353}
Fixes the implementation of wasm exceptions to use a WasmRuntimeError
object, and set the exception tag value as a property of the
object. This guarantees that an uncaught wasm exception is treated
like all other runtime errors.
Bug: v8:6577
Change-Id: I0ab0130444e745178e86c23b3bc9fc9f385c8d05
Reviewed-on: https://chromium-review.googlesource.com/611124
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47346}
The interpreter was not able to call imported wasm functions (hitting
UNIMPLEMENTED). This CL fixes this by creating a "CWasmEntry", which is
signature-specific. It has JS linkage and receives the wasm code object
to call and a buffer containing all arguments (similar to the
interpreter entry). It loads all arguments from the buffer and calls the
given code object.
The c-wasm-entry code objects are cached per instance, such that we
only create them once per signature.
These wasm entry stubs will also allow us to call back to compiled code
from the interpreter, which we might want to do to reduce the slowdown
of executing wasm for debugging.
R=titzer@chromium.org
Bug: chromium:735792
Change-Id: I7fecec3a7bec62a9de40fff115b684759b12a28b
Reviewed-on: https://chromium-review.googlesource.com/600308
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47195}
In order to limit the overall length of error message, limit the output
of string provided by the user. This is implemented by a helper class
which takes the maximum length as template argument and has simple
accessors for the start address and the length of the truncated string.
This is the compromise CL after
https://chromium-review.googlesource.com/c/566815 and
https://chromium-review.googlesource.com/c/594288.
R=titzer@chromium.org
Bug: chromium:740023, chromium:749041, v8:6634
Change-Id: I7c154eb18b3a6befd5ecabbd2f435b015ad71542
Reviewed-on: https://chromium-review.googlesource.com/600547
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47157}
This is a reland of 470a10015d
Original change's description:
> Start migration of try/throw/catch to match proposal.
>
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
>
> It does the following:
>
> 1) Use exception tags instead of integers.
>
> 2) Only handle empty exception signatures (i.e. no values associated
> with the exception tag.
>
> 3) Only handle one catch clause.
>
> 4) Be sure to rethrow the exception if the exception tag does not match.
>
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
>
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
>
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
>
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}
Bug: v8:6577
Change-Id: I41c3309827c292cb787681a95aaef7cf9b931835
Reviewed-on: https://chromium-review.googlesource.com/598968
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47100}
This reverts commit 470a10015d.
Reason for revert: GC stress bot failures.
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/14522
Original change's description:
> Start migration of try/throw/catch to match proposal.
>
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
>
> It does the following:
>
> 1) Use exception tags instead of integers.
>
> 2) Only handle empty exception signatures (i.e. no values associated
> with the exception tag.
>
> 3) Only handle one catch clause.
>
> 4) Be sure to rethrow the exception if the exception tag does not match.
>
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
>
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
>
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
>
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}
TBR=bradnelson@chromium.org,eholk@chromium.org,kschimpf@chromium.org
Change-Id: I01dc8c40cc1057333a988c1d275ce5f457b0cb64
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6577
Reviewed-on: https://chromium-review.googlesource.com/598847
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47090}
This CL does the first baby steps on moving the current (experimental)
exception handling to match that of the WebAssembly proposal.
It does the following:
1) Use exception tags instead of integers.
2) Only handle empty exception signatures (i.e. no values associated
with the exception tag.
3) Only handle one catch clause.
4) Be sure to rethrow the exception if the exception tag does not match.
Note: There are many things that need to be fixed, and are too
numerous to list here. However, the code should have TODO's on each
missing parts of the implementation.
Also note that the code currently doesn't handle nested catch blocks,
nor does it change the throw value being an integer. Rather, the
integer value is still being thrown, and currently is the exception
tag. Therefore, we don't build an exception object. This is the reason
why this CL doesn't handle exceptions that pass values.
Also, the current implementation still can't handle multiple modules
because tag resolution (between) modules has not be implemented yet.
Bug: v8:6577
Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
Reviewed-on: https://chromium-review.googlesource.com/591910
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47087}
The test TestExportImportedMemoryGrowMultipleInstances in
test/mjsunit/wasm/import-memory.js had a TODO about not taking into
account the maximum size for exported memory objects, thus permitting to
grow past thhe maximum specified in the exported memory object.
The check is already in place at wasm-objects.cc:266
(https://cs.chromium.org/chromium/src/v8/src/wasm/wasm-objects.cc?rcl=a01b55b548add5aec1d3d4d8fcdadfa01555c6ea&l=266).
This CL removes the TODO and asserts that growing past maximum for
exported objects fails.
R=ahaas@chromium.org, gdeepti@chromium.org
Change-Id: Ifa69e4e85e04bc2280b629cebb30d400cca9420f
Reviewed-on: https://chromium-review.googlesource.com/593948
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47029}
This reverts commit 072d0e3eb6.
Reason for revert: Performance regressions (https://crbug.com/749041).
Original change's description:
> [wasm] Allow for arbitrarily long error messages
>
> We currently have a fixed limit of 256 characters for error messages
> generated in the decoder. However, we sometimes embed names in it,
> which makes it easy to generate a crash by using long names (e.g. for
> exports) in invalid wasm modules.
> This CL fixes this by switching to a stream based interface, allowing
> to pass arbitrary objects to be printed. With this interface, we can
> easily limit the length of output later.
>
> R=titzer@chromium.org
>
> Bug: chromium:740023
> Change-Id: I2848c31c63a015157e2a3a9458b54e523060cd69
> Reviewed-on: https://chromium-review.googlesource.com/565282
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46860}
TBR=titzer@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:740023, chromium:749041
Change-Id: I005a60d55dcf01d350230f8d98f715bab9c43886
Reviewed-on: https://chromium-review.googlesource.com/593807
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47008}
This brings the wasm-constants.js file inline with that (forked copy) in
the WebAssembly spec repo, which should make it easier to export tests
from V8 to the spec in the future.
R=clemensh@chromium.org
Bug:
Change-Id: I7db23efc2d671f65b614f9dbc97ae2f355f91b04
Reviewed-on: https://chromium-review.googlesource.com/586248
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46894}
We currently have a fixed limit of 256 characters for error messages
generated in the decoder. However, we sometimes embed names in it,
which makes it easy to generate a crash by using long names (e.g. for
exports) in invalid wasm modules.
This CL fixes this by switching to a stream based interface, allowing
to pass arbitrary objects to be printed. With this interface, we can
easily limit the length of output later.
R=titzer@chromium.org
Bug: chromium:740023
Change-Id: I2848c31c63a015157e2a3a9458b54e523060cd69
Reviewed-on: https://chromium-review.googlesource.com/565282
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46860}
Extend the errors.js mjsunit test to also check for the message in the
generated errors. This will help catch bugs later, e.g. when
refactoring the way we output errors:
https://chromium-review.googlesource.com/c/565282
Drive-by 1: Fix a superfluous period in one error message.
Drive-by 2: Fix a weird exception catching construct in the test.
R=titzer@chromium.org
Change-Id: I1c2e92fb2c34a481cbf8802153f8502452d45348
Reviewed-on: https://chromium-review.googlesource.com/582960
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46858}
The code was already there, but there was a bug in it: Because of the
missing reference, we were only updating a *copy* of the signature map,
hence the update had no effect.
This intentially is a minimal CL, in order to allow for easy
backmerging.
More mitigations and tests are coming in a separate CL.
R=titzer@chromium.org
Change-Id: Ifb462093f4b8f4d5380b6774636537c67c2b676c
Reviewed-on: https://chromium-review.googlesource.com/570278
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46664}
- Implement js-api changes for WebAssembly.Memory to accept a shared parameter
- Update allocation to use SharedArrayBuffers
BUG=v8:6532
R=binji@chromium.org, bradnelson@chromium.org
Change-Id: I021491217568751b06fbd7b4b08b1dd88910e21d
Reviewed-on: https://chromium-review.googlesource.com/564058
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46543}
There are other things to export beside functions. Thus, also print the
export kind when printing an error for duplicate export names.
R=titzer@chromium.org
Change-Id: I7477040dda274a16cfd776d7ac8db6e50a197b97
Reviewed-on: https://chromium-review.googlesource.com/564940
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46503}
This CL refactors the WasmMemoryObject and WasmInstanceObject classes to
use WeakFixedArray instead of using a doubly-linked list of instances. This
simplifies the lifetime management of instances by not requiring them to
be unlinked from this list upon GC. It also simplifies the iteration over
the instances using a given WasmMemoryObject.
Note that, contrary to my naive assumption at the outset, it is still necessary for the InstanceFinalizer (called upon a WasmInstanceObject death) to unlink itself from a WasmMemoryObject's instances list, due to finalizer ordering.
R=deepti@chromium.org, mlippautz@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2972803002
Cr-Commit-Position: refs/heads/master@{#46482}
Tsan figured out that I called compilation_units_.empty() outside a
lock.
Original message:
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: Ia83560d1c70f0802271a88c514e0d1cb0458f6c4
Reviewed-on: https://chromium-review.googlesource.com/561458
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46454}
When providing scope information (containing the value of local
variables of live stack frames), decode the local variable names of all
functions in a wasm module and store this in the WasmDebugInfo
structure.
Use these names to actually name the reported locals, instead of using
the default names "param#<d>" and "local#<d>". These names are only used
as fallbacks for locals which were not assigned a name.
R=titzer@chromium.org,kozyatinskiy@chromium.org
BUG=v8:6245
Change-Id: Ibf7d30e392248ef5590177cd8b6329239b45e018
Reviewed-on: https://chromium-review.googlesource.com/548495
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46379}
The jsapi-harness test runs the JS-API spec tests of WebAssembly, which
get fetched from github when 'gclient sync' is executed. Without
'gclient sync' the harness may executed a version of the tests which is
older than required by the harness. In this CL I add a suggestion to
the test to run 'gclient sync' which is shown when the test is failing.
R=marja@chromium.org
Change-Id: I36d03bebc4d6cc554eefd4eb376c3d309b7ee5b9
Reviewed-on: https://chromium-review.googlesource.com/558419
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46375}
This CL updates the wasm spec tests. In addition it adds an
assertNotEquals function to mjsunit.js, and it fixes the test harness
to not call quit() because it causes a dead-lock in combination with
async compilation.
R=rossberg@chromium.org
Change-Id: I50cf737993adb3e2bd27977efe7e20e304b89078
Reviewed-on: https://chromium-review.googlesource.com/558077
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46366}
This CL landed on top of another CL which I want to revert.
This reverts commit 27b0d6a9fc.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Update spec tests
>
> Update the spec tests in v8 to the most recent version.
>
> R=rossberg@chromium.org
> CC=titzer@chromium.org
>
> Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
> Reviewed-on: https://chromium-review.googlesource.com/552155
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46346}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,ahaas@chromium.org
Change-Id: I82e4a2887bcb867d3572b78c36a20adc05df0903
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558040
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46352}
This reverts commit ca93156294.
Reason for revert: tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/16007
Original change's description:
> [wasm] Allow the initialization of a single compilation unit
>
> This CL adds a new function {InitializeCompilationUnit} to initialize
> a single compilation unit and not just all compilation units at once.
> This is necessary for streaming compilation eventually. This also
> required some refactoring on how the working queue for compilation units
> works. Previously the synchronization was done with an atomic counter,
> now it is done with a lock. Note that the code to finish compilation
> of a module still only works if the working queue gets only empty when
> all work is done. I plan to change this in a different CL.
>
> Since the code would not be tested without streaming compilation, I added
> an experimental flag and a test to test the new code.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
> Reviewed-on: https://chromium-review.googlesource.com/550096
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46348}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: Ied6532f05463c0b78c8b8f5307d44640bcca8316
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558224
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46350}
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
Reviewed-on: https://chromium-review.googlesource.com/550096
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46348}
Update the spec tests in v8 to the most recent version.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
Reviewed-on: https://chromium-review.googlesource.com/552155
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46346}
In our internal code, we should only use pending exceptions. They will
be converted to scheduled exceptions on the API boundary.
Hence, the ErrorThrower just sets a pending exception; it should never
have to think about scheduled exceptions. The new
ScheduledErrorThrower inherits from ErrorThrower and reschedules any
pending exceptions in its destructor (turning them into scheduled
exceptions).
In some situations, there might already be a scheduled exception, e.g.
when calling other API methods (v8::Value::Get). In this case, the
ErrorThrower should also not set another pending exception. For the
reasons mentioned above, this can only be handled in the
ScheduledErrorThrower, which is used the API methods.
This fixes one DCHECK failure and one TODO about scheduled exceptions
if no instance can be created, because the start function throws.
R=mtrofin@chromium.org, mstarzinger@chromium.org
BUG=v8:6232,chromium:736256
Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
Reviewed-on: https://chromium-review.googlesource.com/548641
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46314}
If a String object contains unicode, the returned {ToCString()} may
actually longer than the {length()} of the String.
But it's always null-terminated, so we can just print it without
explicitly passing a length.
R=ahaas@chromium.org
Change-Id: I3398f151d70ed459ecd8093ea18409670a7374c7
Reviewed-on: https://chromium-review.googlesource.com/548058
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46225}
Test that unicode identifiers can be used for imports and exports, and
that unicode function names appear correctly in error messages.
R=ahaas@chromium.org
Change-Id: Ic6ac77159c275845886b2eb779cf59edb8cba9ea
Reviewed-on: https://chromium-review.googlesource.com/548315
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46220}
On an error during {ProcessExports()}, we would just continue
execution, resulting in a DCHECK failure later.
I did not find any tests for exported globals, so I added a few
(including a regression test for the referenced bug).
R=ahaas@chromium.org
BUG=chromium:734295
Change-Id: I35370de934c274f870680c662ef848c72268a7bc
Reviewed-on: https://chromium-review.googlesource.com/539401
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46064}
This makes sure that the coercion of global import values to numbers
remains non-observable to JavaScript. It allows instantiation failures
to fall back to JavaScript proper without accidentally causing some
side-effect to happen twice. Also coercions might invalidate previous
checks done during linking or throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6431
BUG=v8:6431
Change-Id: Ibe2f7a336bc0fb25532d526746ecc802e04bbd5c
Reviewed-on: https://chromium-review.googlesource.com/512544
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46051}
There exists a hidden assumption in V8 that neither foreground nor
background tasks own any memory. For asynchronous WebAssembly
compilation this assumption was wrong, which causes crashes when V8 shut
down before the compilation finished.
With this CL I change the way asynchrous compilation happens. In the
existing implementation each compilation stage provided its own task
which could be spawned either in foreground or background. With this CL
each stage only provides a state, and a generic CompileTask executes on
that state. There exists exactly one state at a time.
To have exactly one state at a time I combined the stages
ExecuteCompilationUnits and FinishCompilationUnits to a single stage. In
addition I removed the WaitForBackgroundTasks stage and added a
CancelableTaskManager to the AsyncCompileJob instead to do the waiting.
BUG=v8:6436
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I2eb61f74235c65524ce720c474eaf99ae7472c81
Reviewed-on: https://chromium-review.googlesource.com/532993
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45908}
We were emitting the table index once in the element section instead of
once per element segment. This did not cause failures because we never
had more than one element segment.
This CL fixes this, and adds a test for more than one segment.
R=rossberg@chromium.org
Change-Id: I13923baf3dae383c72760286e24242d0ad55c4db
Reviewed-on: https://chromium-review.googlesource.com/527155
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45857}
* add functionality to wasm-module-builder.js to emit the module name
in the name section.
* extend WasmModule to store the module name length and offset.
* add functionality to module-decoder.cc to decode the module name.
* use the module name for printing stack traces. more uses should
follow.
* extend one message test to contain a module name.
R=ahaas@chromium.org
Change-Id: I94e6f1f2eb99cb656a92a85bb7afe0742292046f
Reviewed-on: https://chromium-review.googlesource.com/530366
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45846}
This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.
R=ahaas@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}
This wraps up the move to explicit APIs, i.e.
instantiateStreaming/compileStreaming.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icc8280b2b3ad35acb90cc0beebe3acd7581179d7
Reviewed-on: https://chromium-review.googlesource.com/525141
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45719}
TBR=ishell@chromium.org
Bug: v8:6457
Change-Id: I09d7d6ff8460688b7ddf25f733aea73a620db953
Reviewed-on: https://chromium-review.googlesource.com/523037
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45699}
This CL updates the hook for the WebAssembly spec repository, and it
updates the WebAssembly spec tests. The WebAssembly spec tests have to
be updated manually with the tools/wasm/update-wasm-spec-tests.sh
script. Mircea, I saw that you updated the WebAssembly spec repository
last time. Can you please take a look?
UPDATE: I improved the update script slightly, and there is one
additional JS API test we fail now and have to fix eventually.
R=mtrofin@chromium.org
Change-Id: I3c0df9cee64d444147db47daa0c1936edf116173
Reviewed-on: https://chromium-review.googlesource.com/509257
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45692}
Most prototype implementations are not fully supported in the
interpreter. This is the case at least for exception handling, simd, and
atomics. Any function can be redirected to the interpreter though,
either by passing --wasm-interpret-all, or by dynamically redirecting to
the interpreter for debugging.
Making the flags experimental keeps the fuzzer from playing around with
these flags.
Drive-by: Refactor tests which explicitly set the prototype flag to use
a new scope for that.
R=ahaas@chromium.org
BUG=chromium:727584
Change-Id: I67da79f579f1ac93c67189afef40c6524bdd4430
Reviewed-on: https://chromium-review.googlesource.com/519402
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45639}
We're now using explicit APIs.
Bug:
Change-Id: I4a4248e44543f6e7dfcbdc66456e610fb98ff5ee
Reviewed-on: https://chromium-review.googlesource.com/513406
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45500}
This makes sure that property lookups on the provided imports object are
non-observable to JavaScript. It allows instantiation failures to fall
back to JavaScript proper without accidentally calling accessors twice.
Also accessors might invalidate previous checks done during linking or
throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-719384
BUG=chromium:719384
Change-Id: I3db2672d2a496110f705d02b82878e70cd5d701f
Reviewed-on: https://chromium-review.googlesource.com/509552
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45481}
The validation of utf8 strings in WebAssembly modules used the character
kBadChar = 0xFFFD to indicate a validation error. However, this
character can appear in a valid utf8 string. This CL fixes this problem
by duplicating some of the code in {Utf8::CalculateValue} and inlining
it directly into Utf8::Validate. Note that Utf8::Validate is used only
for WebAssembly.
Tests for this change are in the WebAssembly spec tests, which I will
update in a separate CL.
R=vogelheim@chromium.org
Change-Id: I8697b9299f3e98a8eafdf193bff8bdff90efd7dc
Reviewed-on: https://chromium-review.googlesource.com/509534
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45476}
This is to avoid ClusterFuzz picking up and using those calls.
With the proper syntax (no whitespace), they are recognized as runtime
calls and will be checked against a whitelist.
R=mstarzinger@chromium.org
BUG=chromium:724459
Change-Id: I5533f066feeb66f622230b12f79f9d227e2b2465
Reviewed-on: https://chromium-review.googlesource.com/509575
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45475}
As per spec, (https://github.com/WebAssembly/design/pull/1068), we
don't have compile/instantiate overloads anymore, instead, we
have explicitly named members.
This change introduces the new APIs, implements instantiateStreaming
based on compileStreaming, and uses the existing embedder mechanism.
It does not yet remove the functionality from compile/instantiate -
we do that after we adopt the new APIs on the blink side.
Also, it temporarily handles exceptions on the v8 side, which is also
something we'll move to the blink side.
Bug:
Change-Id: I77673b1c0d395dfcf13b2f25464fd5dfd99c8d82
Reviewed-on: https://chromium-review.googlesource.com/508852
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45411}
