This was left over from the previous CL to change S128LoadMem/S128StoreMem to
use prefixed opcodes. Decoding prefixed opcodes already checks for the
prototype flag.
BUG=V8:6020
R=bbudge@chromium.org
Review-Url: https://codereview.chromium.org/2946303002
Cr-Commit-Position: refs/heads/master@{#46108}
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}
If one wasm instance imports an exported function of another instance,
we unwrap the js-to-wasm wrapper of the export and use the underlying
code object directly. However, the code object does not keep the wasm
instance alive. It is only connected via a WeakCell.
With this CL, we explicitly store a FixedArray of all wasm instances
from which we imported functions to keep them alive at least as long as
the instance which imports the code.
R=mtrofin@chromium.org, ahaas@chromium.org
BUG=chromium:734345
Change-Id: I8dcfc9a4ea2d791a62d8cb7255039e481c50bdfd
Reviewed-on: https://chromium-review.googlesource.com/539738
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46062}
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}
The constructor of WireBytesRef checks that offset+length is still in
the uint32_t range. This CL avoids triggering this check on illegally
size strings.
R=ahaas@chromium.org
BUG=chromium:734246
Change-Id: Iab5c7013aa3e0ac5060bc4733e712a1652679b1a
Reviewed-on: https://chromium-review.googlesource.com/539402
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46050}
https://codereview.chromium.org/2632713003 with workaround for old GCC.
Drive-by: fix unused variable in src/wasm/wasm-js.cc
Bug:chromium:457078
Change-Id: I6c1b65076bae783c31869552bc87d05c28550e26
Reviewed-on: https://chromium-review.googlesource.com/538463
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46049}
It is possible that the foreground task is unable to clear the
scheduled unfinished work, eventually leading to an OOM.
We use either code_range on 64 bit, or the capacity of the code space,
as a heuristic for how much memory to use for compilation.
The change avoids blocking the background threads while we're over
the memory threshold. This is to avoid starving the GC.
Bug: v8:6492, chromium:732010
Change-Id: Ic2647d9fa71af4f8cdd2149a434b107cbed3a6c3
Reviewed-on: https://chromium-review.googlesource.com/540763
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46029}
This reverts commit 1835b4b177.
Reason for revert: This has a perf regression, wasn't ready just yet.
Original change's description:
> Revert "Revert "[wasm] Throttle the amount of unfinished work to avoid OOM""
>
> This reverts commit 4ee4918195.
>
> Reason for revert: Fix: in d8, blocking all the bg threads starves the GC.
>
> Original change's description:
> > Revert "[wasm] Throttle the amount of unfinished work to avoid OOM"
> >
> > This reverts commit 1280954d3a.
> >
> > Reason for revert: Speculative, GC stress bots started taking much longer after this change.
> >
> > Original change's description:
> > > [wasm] Throttle the amount of unfinished work to avoid OOM
> > >
> > > It is possible that the foreground task is unable to clear the
> > > scheduled unfinished work, eventually leading to an OOM.
> > >
> > > We use either code_range on 64 bit, or the capacity of the code space,
> > > as a heuristic for how much memory to use for compilation.
> > >
> > > Bug: v8:6492, chromium:732010
> > > Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> > > Reviewed-on: https://chromium-review.googlesource.com/535017
> > > Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#46017}
> >
> > TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
> >
> > Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Bug: v8:6492, chromium:732010
> > Reviewed-on: https://chromium-review.googlesource.com/540270
> > Reviewed-by: Bill Budge <bbudge@chromium.org>
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46020}
>
> TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: I1e7a1d0202c3161f9a7139e8895eebf472473ad3
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6492, chromium:732010
> Reviewed-on: https://chromium-review.googlesource.com/540841
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46022}
TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,mtrofin@google.com,ahaas@chromium.org
Change-Id: Ic1351325173b233be3972ff3c159c035838fa963
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540842
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46023}
This reverts commit 4ee4918195.
Reason for revert: Fix: in d8, blocking all the bg threads starves the GC.
Original change's description:
> Revert "[wasm] Throttle the amount of unfinished work to avoid OOM"
>
> This reverts commit 1280954d3a.
>
> Reason for revert: Speculative, GC stress bots started taking much longer after this change.
>
> Original change's description:
> > [wasm] Throttle the amount of unfinished work to avoid OOM
> >
> > It is possible that the foreground task is unable to clear the
> > scheduled unfinished work, eventually leading to an OOM.
> >
> > We use either code_range on 64 bit, or the capacity of the code space,
> > as a heuristic for how much memory to use for compilation.
> >
> > Bug: v8:6492, chromium:732010
> > Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> > Reviewed-on: https://chromium-review.googlesource.com/535017
> > Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46017}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6492, chromium:732010
> Reviewed-on: https://chromium-review.googlesource.com/540270
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46020}
TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: I1e7a1d0202c3161f9a7139e8895eebf472473ad3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540841
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46022}
This reverts commit 1280954d3a.
Reason for revert: Speculative, GC stress bots started taking much longer after this change.
Original change's description:
> [wasm] Throttle the amount of unfinished work to avoid OOM
>
> It is possible that the foreground task is unable to clear the
> scheduled unfinished work, eventually leading to an OOM.
>
> We use either code_range on 64 bit, or the capacity of the code space,
> as a heuristic for how much memory to use for compilation.
>
> Bug: v8:6492, chromium:732010
> Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> Reviewed-on: https://chromium-review.googlesource.com/535017
> Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46017}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540270
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46020}
It is possible that the foreground task is unable to clear the
scheduled unfinished work, eventually leading to an OOM.
We use either code_range on 64 bit, or the capacity of the code space,
as a heuristic for how much memory to use for compilation.
Bug: v8:6492, chromium:732010
Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
Reviewed-on: https://chromium-review.googlesource.com/535017
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46017}
- Use correct prefixes for SIMD/Atomics ops
- S128 LoadMem/StoreMem should not use 0xc0/0xc1 opcodes, these are now
being used for sign extension
- S128 LoadMem/StoreMem should use prefixed opcodes
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2943773002
Cr-Commit-Position: refs/heads/master@{#46016}
For functions without any calls, there is no value in executing a stack
check. The current frame is materialized at that point anyway.
Note that for loops, we still emit additional stack checks in the loop
header.
For unity, the reduction in code size is moderate (0.53%), as only 4000
of the 34000 functions are leaf functions (no calls). However, we also
save some compile time and gain performance, so this is still worth
doing it.
Drive-by: Fix the effect chain generated in {StackCheck()}.
R=mstarzinger@chromium.org, ahaas@chromium.org
Change-Id: Ia6ec58d0ea46de02634c923cdf8e6e08d8902c59
Reviewed-on: https://chromium-review.googlesource.com/533333
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@{#46013}
- Eliminates S32x4Shuffle, S16x8Shuffle opcodes. All shuffles are subsumed
by S8x16Shuffle. This aligns us with the latest WASM SIMD spec.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2923103003
Cr-Commit-Position: refs/heads/master@{#45929}
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}
This gives the embedder more context for deciding whether code
generation should be allowed or not, or they can chose to include the
code in a report.
BUG=chromium:732736
R=ahaas@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibbaa3d0574319d290f15565be3eed2ee4d3dda36
Reviewed-on: https://chromium-review.googlesource.com/532875
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45905}
This removes the {IsWasm} and {IsAsmJs} methods, which tested a
ModuleOrigin for a specific constant.
These methods do not comply with our naming conventions, and we don't
have such methods for other enums.
Drive-by: Refactor the code which used these methods for better
readability and maintainability.
R=ahaas@chromium.org, kschimpf@chromium.org
BUG=v8:6474
Change-Id: I98eb4dba5420eaa9452ae6f27598ec8b581a0984
Reviewed-on: https://chromium-review.googlesource.com/530229
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45888}
Once a buffer has been externalized, V8 is no longer responsible for managing
the memory. The fact that V8 was freeing was leading to double free errors once
Blink's GC got around to freeing the buffer too.
Bug: chromium:730171, chromium:731046
Change-Id: Ib18a7e37cafd51bce0c5a983d5cf8f3e64eb2c13
Reviewed-on: https://chromium-review.googlesource.com/530132
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45882}
Avoid constructing zones and large zone objects when initializing
WasmCompilationUnit. The main reason we did that is so we can cache
the CEntryStub node, which requires a code object, obtainable only
on the main thread. We need that value, however, on background threads,
which is also where we need the aforementioned large objects. We only
need that for the WasmCompilationUnits being currently compiled, which
is a number proportional to the number of background threads provided
by the embedder. Specifically, one zone is needed only for the duration
of the background compilation, while the second zone needs to survive
past that, so the compilation results may be committed to the GC heap
as Code objects.
The problem with these large objects is that the first allocation
in a Zone is at minimum 8KB. We used to allocate 2 zones. For
modules with 200K functions, that means 3.2GB of memory pre-allocated
before any of it is actually needed.
This change attaches a Handle to the CEntryStub on the WasmCompilationUnits,
and delays zone creation to when needed. The change also adds a way to
cache CEntryStubs in a JSGraph from a given Code handle - limited to the
scenario needed by wasm (and removable once we get wasm off the GC heap,
which subsumes removing this dependency on CEntryStubs)
An additional constraint for this change is that we want it to be easily
back-mergeable to address chromium:723899.
For the wasm payload in question, collecting the max memory used by d8
using /usr/bin/time --format='(%Xtext+%Ddata %Mmax)', we get the
following numbers (in KB):
- unchanged: 3307480
- patch 1: 1807140 (45% reduction)
- patch 3: 1230320 (62% reduction from first)
- patch 5/6: 519368 (84% reduction from first)
Bug: chomium:732010, chromium:723899
Change-Id: I45b96792daf8a9c8dc47d45fb52da75945a41401
Reviewed-on: https://chromium-review.googlesource.com/530193
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45880}
In many places in WasmModule and contained structs we store references
into the wire bytes as pairs of offset and length.
This CL introduces a WireBytesRef struct which encapsulates these two
connected fields. This makes it easier to pass them and assign them as
one unit.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I4f2a40d848a51dc6f6f599f9253c3c6ed6e51627
Reviewed-on: https://chromium-review.googlesource.com/530687
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45859}
This CL is the first step in introducing a compilation manager for
asynchronous compile jobs in WebAssembly.
The compilation manager holds a list of currently active
AsyncCompileJobs. With the compilation manager these compile jobs get
deallocated when the isolate shuts down. Note that this CL is not enough
to provide a graceful isolate shutdown. For this we have to wait for all
compilation tasks to finish before we shut down, and we have to make the
tasks stateless. I plan to do these changes in separate CLs.
R=clemensh@chromium.org, mtrofin@chromium.org
BUG=v8:6436
Change-Id: I9a6e165dd2ef6d33944ca303fed49f7940eea7a2
Reviewed-on: https://chromium-review.googlesource.com/528079
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45858}
This is a testing-only function, which is semantically equivalent to a
SyncCompile followed by SyncInstantiate.
We add a new SyncCompileAndInstantiate function to do those two steps
in one go, and use this method instead.
For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is
introduced.
This is part of our effort to reduce the number of special paths for
testing. It is connected with
https://chromium-review.googlesource.com/529210, but should not
conflict with it.
After landing both CLs, we can later also get rid of
InstantiateModuleForTesting.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc
Reviewed-on: https://chromium-review.googlesource.com/529844
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45852}
This CL removes unnecessary code duplication in the fuzzer code. Instead
of having special testing functions to compile and instantiate a
WebAssembly module, we now just call SyncCompile and SyncInstantiate.
This also fixed a problem when the fuzzer generated a GrowMemory
instruction.
BUG=v8:6474
R=clemensh@chromium.org
Change-Id: I5f2f23349b5866ea67be20a0826271791e1a013e
Reviewed-on: https://chromium-review.googlesource.com/529210
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45851}
* 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}
Introduce base::make_unique as a replacement for std::make_unique,
introduced in C++14.
Use it in the wasm code base to construct new objects and wrap them in
a unique_ptr, making the code more compact and readable.
R=ahaas@chromium.org
BUG=v8:6474
Change-Id: I2b9c800edc456021b057f1e69d3c144889b1c9f4
Reviewed-on: https://chromium-review.googlesource.com/529167
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45822}
- Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
- All vector comparisons return v128 type.
- Eliminates b1xN and, or, xor, not.
- Selects take a v128 mask vector and are now bit-wise.
- Adds a new test for Select, where mask is non-canonical (not 0's and -1's).
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2919203002
Cr-Commit-Position: refs/heads/master@{#45795}
This CL extracts the classes CompilationHelper, InstantiationHelper,
and AsyncCompileJob from wasm-module.cc and puts them into
module-compiler.{h|cc}. This is necessary to introduce a
WasmCompilationManager which is known to the isolate and manages the
lifetime of all AsyncCompileJobs.
In addition to the mechanical changes of copying the code and splitting
class declaration from instantiation, I did the following changes:
* I renamed the CompilationHelper to ModuleCompiler.
* A finalizer function is passed to the InstantiationHelper as a
parameter.
* Adjusted UpdateDispatchTable in wasm-module.cc to make it available in
wasm-module.h, also with the internal signature.
* Duplicate the ResolvePromise/RejectPromise helper functions.
I did not rename InstantiationHelper because I could not come up with a
good name, and it could benefit from a small special refactoring anyways.
BUG=v8:6436
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I4abe854c36dfc995b34c9d7b3e7ec0f4f0aa562e
Reviewed-on: https://chromium-review.googlesource.com/525572
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45773}
The old implementation of Table.Set in wasm-js.cc accessed information
which should be hidden from this level of abstraction, e.g. the internal
structure of a WasmTableObject. With this CL, all that is done in
wasm-js.cc is the extraction of parameters. The actual logic is happening
in wasm-module.{h|cc}. This CL will also make refactoring wasm-module.cc
easier.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: Ifbce6f739459dffc9f9d47e4cd8227638867f3e9
Reviewed-on: https://chromium-review.googlesource.com/525694
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45754}
Fixes issues raised in CL https://codereview.chromium.org/2887193002.
That is:
1) Remove using mutex in Isolate::InitializeCounters().
2) Use counters_shared_.get() instead of counters_ (and hence, also
remove field counters_).
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2919953003
Cr-Commit-Position: refs/heads/master@{#45743}
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}
This places in the scaffolding for completely relying on the embedder
for these APIs. Once Chrome uses these instead of the old APIs,
we can cleanup further by removing the old callback insertion points
and not exposing the streaming APIs if callbacks aren't provided.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I15abd257257be512674b18aa4af2e0a0153612a5
Reviewed-on: https://chromium-review.googlesource.com/520602
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45696}
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}
The problem with enums is that neither is_integral, nor is_signed or
is_unsigned is true for them. Thus, comparison with our CHECK/DCHECK
macros always just uses the default comparison, which fails if the
signedness of the underlying integer types does not match.
This CL fixes this by considering the underlying integer type of an
enum to choose the right comparison operator.
R=ishell@chromium.orgCC=ahaas@chromium.org
Change-Id: I5ef56d1b86228e879f5866967ab7e709f1e97f0b
Reviewed-on: https://chromium-review.googlesource.com/518123
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45593}
Both lazy initialization and static initialization (via static
initializer) are bad. Fortunately, the arrays we are constructing are
constant anyway, so we can just compute them at compile time. This is
enforced by making them constexpr.
This also saves all code needed for the initialization, and makes
accesses to the tables faster, as they don't need any atomic operations
(via LazyInstance).
R=ahaas@chromium.org
Change-Id: I7d3ba9b0f2602f596a6c71c8c567e0d1bc306268
Reviewed-on: https://chromium-review.googlesource.com/517083
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45589}
For lazy compilation, we encode information about table exports in the
deoptimization data. This information is rebuilt on each instantiation,
so we need to reset it when reusing code objects from another instance.
R=ahaas@chromium.org
BUG=chromium:727219
Change-Id: I90557ef06e692d0a8323223cac26679efcfa408b
Reviewed-on: https://chromium-review.googlesource.com/517945
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45559}
It happens frequently that unrelated compiler errors lead to the
instantiation of {read_leb_tail} with an invalid {byte_index}, which
again triggers compiler errors.
This change fixes this, such that illegal instantiation just triggers a
static_assert and nothing more. This helps to spot the actual error.
Drive-by: Mark {Min} and {Max} constexpr, such that they can produce
constexpr results. Note that the result will only be constexpr if both
arguments are constexpr.
R=ahaas@chromium.org
Change-Id: I35d6865a7f569d72ace0debb045ac615cfd87d92
Reviewed-on: https://chromium-review.googlesource.com/518005
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45558}
Parallel compilation should only be chosen if there are background threads
available. Otherwise, the overhead of orchestrating (non-)parallel work
can be omitted by just compiling synchronously.
R=ahaas@chromium.org
Change-Id: I333fb87e07fdb3260ab4c9c2c1885a1df4c5e4ef
Reviewed-on: https://chromium-review.googlesource.com/513062
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45555}
This removes a lot of special handling for the predictable platform.
Instead of executing spawned foreground and background tasks
immediately (i.e. inside the scope that spawns the tasks), just add
both to the foreground task queue.
This avoids existing special handling for predictable mode in wasm
async compilation, and should fix current failures on the predictable
bot.
BUG=v8:6427
Change-Id: Idbaa764a3dc8c230c29f3937d885e12174691ac4
Reviewed-on: https://chromium-review.googlesource.com/509694
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45538}
