Call the templated handle(T) function instead of
Handle<T>() as it's slighly simpler to read.
Bug:
Change-Id: I7d8dc6ffae1dc1c609cd6bce230adbe62aaf451b
Reviewed-on: https://chromium-review.googlesource.com/509568
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45430}
This fixes crashes during validation when trying to construct modules
with excessively large function tables. The {WasmModuleBuilder} now
gracefully checks against existing WebAssembly implementation limits.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-715455
BUG=chromium:715455
Change-Id: Ia9738cb0b49a1eb4caf073b75301c0303f295699
Reviewed-on: https://chromium-review.googlesource.com/509530
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45429}
In the current implementation the decision to inline polymorphic function
calls applies to all functions. Either we inline all of them or none of
them. Also, we decide to inline if the size of one of function is less
than the FLAG_max_inlined_nodes.
This cl changes it to a decision on individual functions. In the case of
polymorphic calls, we might inline some of the functions and not inline
others.
Bug:
Change-Id: I2f4049b5e55445b4858b260d289c96090c6aaa74
Reviewed-on: https://chromium-review.googlesource.com/508668
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45428}
On map change of an object this patch checks that
- either GC was notified about this change,
- or the change leaves the slot set of the object the same.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2886223002
Cr-Commit-Position: refs/heads/master@{#45427}
This is in order to avoid triggering the generation of deopt entries
later during code assembly.
R=jarin@chromium.org
Bug: v8:6048
Change-Id: I51fb508cfc5d715b6a5b2fded90b19c9f21d4d9f
Reviewed-on: https://chromium-review.googlesource.com/508789
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45426}
Task creation often dominates the actual work that is being done.
Bug: chromium:722989
Change-Id: Ibdd6ffa6f3154f17dc6ccbd30475710b97e802e7
Reviewed-on: https://chromium-review.googlesource.com/508783
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45425}
This adds reporting of linking failures (i.e. module instantiation)
similar to the existing reporting for validation failures. Note that
the messages in question are deterministic and can be tested.
R=clemensh@chromium.org
Change-Id: Ibecebefb86f1d878f626702c05fd0cb21189dc2a
Reviewed-on: https://chromium-review.googlesource.com/507488
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45421}
Reason for revert:
Going a different way with this, as Chromium don't want the additional files.
Original issue's description:
> Add DEPS.chromium for recursive DEPS tracking.
>
> DEPS.chromium allows the Chromium build system's DEPS to recurse into V8's own
> dependencies. Initially, this is populated with some tests files for the ARM64
> simulator.
>
> BUG=chromium:718439
>
> Review-Url: https://codereview.chromium.org/2880293002
> Cr-Commit-Position: refs/heads/master@{#45310}
> Committed: f8a6c6c48eTBR=machenbach@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:718439
Review-Url: https://codereview.chromium.org/2891323002
Cr-Commit-Position: refs/heads/master@{#45420}
This simplifies the growing strategy used in {ZoneBuffer} and also tunes
the initial sizes used for various instances of these buffers. Note that
such a {ZoneBuffer} is used for entire modules and individual function
bodies.
R=clemensh@chromium.org
Change-Id: I99a0898589984e1830c681845fabb0ed5f8317ab
Reviewed-on: https://chromium-review.googlesource.com/508711
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45419}
In a recent CL I moved the corpus of the wasm fuzzer and of the
wasm-asmjs fuzzer to a different directory
(wasm_corpus and wasm_asmjs_corpus) so that the corpus is not executed
on the try-bots. With this CL I remove the old corpus from the
.gitignore file.
In addition I removed the hooks for wasm_corpus and
wasm_asmjs_corpus from the V8 DEPS file, because in a V8 checkout
they are not used anyway.
I also added code to the test runner to delete all *.wasm files
from the directories test/fuzzer/wasm and test/fuzzer/wasm_asmjs.
This code should be removed in a week, but it will help my coworkers
to cleanup their V8 checkout.
R=bradnelson@chromium.orgCC=machenbach@chromium.org
Change-Id: I9fdf9d77b71b133f84f7e744763d65fdf127d624
Reviewed-on: https://chromium-review.googlesource.com/505614
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45417}
In crrev.com/2856103002 sentinel frequency values were introduced, using
NaN as the sentinel. However the comparison function was not *fully*
updated to support these - comparing two NaNs would give ambiguous
results. This caused test failures when building with VS 2017, probably
because of subtle changes in the arrangement of nodes in the tree.
This change uses the the node ID to break ties. An alternative would be
to use a non-NaN sentinel value.
R=bmeurer@chromium.org
BUG=chromium:722480
Review-Url: https://codereview.chromium.org/2894433004
Cr-Commit-Position: refs/heads/master@{#45415}
Introduce a flag --max-inlined-nodes-absolute that is used to limit the
number of nodes that we inline even in the presence of small function
inlining, so that TurboFan graphs don't grow arbitrary large.
BUG=chromium:724084,v8:6395,v8:6278,v8:6344,v8:6394
TBR=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2894523005
Cr-Commit-Position: refs/heads/master@{#45414}
This refactoring makes it easier to write advanced tests and
gives full control over what's happening to the test code.
It also forces description for every test.
BUG=none
Review-Url: https://codereview.chromium.org/2891213002
Cr-Commit-Position: refs/heads/master@{#45412}
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}
Port 73d21080c9
Original Commit Message:
Now that the optimized code hangs off the feedback vector, it is possible
to check whether a function has optimized code available every time it's
called in the interpreter entry trampoline. If optimized code exists, the
interpreter entry trampoline 'self-heals' the closure to point to the
optimized code and links the closure into the optimized code list.
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6246
LOG=N
Review-Url: https://codereview.chromium.org/2897483002
Cr-Commit-Position: refs/heads/master@{#45410}
- moved all extensions to inspector_test.cc;
- properly supported multiple context groups and sessions;
- better isolation between components;
- better infrastructure in protocol-test.
BUG=chromium:590878
Review-Url: https://codereview.chromium.org/2890463004
Cr-Commit-Position: refs/heads/master@{#45409}
If the new Free function is not implemented, but we are freeing a Normal
allocation, as opposed to one with guard regions, we can fall back on the
existing Free function.
Because guard regions are not yet used in normal circumstances, this will let
embedders who have not implemented the improve ArrayBuffer::Allocator interface
to continue working.
Bug:
Change-Id: I2e30b523ef7493ab288110b90d8f994bfcfbc9b7
Reviewed-on: https://chromium-review.googlesource.com/508897
Commit-Queue: Eric Holk <eholk@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45408}
WebAssembly needs to be able to allocate memory with guard regions, which
requires more functionality from the array buffer allocator. This change adds
functions for reserving memory regions and changing the memory protection.
This CL also includes some minor refactoring of the code to free array buffers.
Bug: chromium:720302
Change-Id: Iab9a266003043b0d36592a79668d1eea53952abf
Reviewed-on: https://chromium-review.googlesource.com/506377
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45407}
Split BytecodeGenerator::VisitSuspend into two pieces, one for
building the suspension code and one for resumption (these
are split into separate Build methods for convenience).
Each gets its own RegisterAllocationScope, which allows us to
reduce the register file size of the empty generator by 1.
For consistency, rename VisitGeneratorPrologue() to
BuildGeneratorPrologue() to match the names of the two
newly-created methods.
This relands the patch originally committed in
98927ea51b, as the test failure
due to that change was a code flushing bug. Code flushing was
disabled in de4a4095cf.
R=rmcilroy@chromium.org
Bug: v8:6379
Change-Id: Ifb4deafea99693c0a4e8646cf4e9884c7374cfc6
Reviewed-on: https://chromium-review.googlesource.com/508814
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45406}
Varblock scopes can be treated as the "same scope" as their surrounding
function scope for the purposes of hole check elimination, as
source position comparison is sufficient to determine statically that
uses in the varblock scope are after initialization in the function scope.
This allows the elimination of hole checks of lexically-bound parameter
variables in functions with complex parameters, including rest parameters.
The pre-existing code compared DeclarationScopes for legacy reasons:
varblock scopes (and Scope::GetClosureScope()) did not exist at the
time this code was originally written.
R=neis@chromium.org
Bug: v8:6344, v8:6414
Change-Id: Ie787d58d1ea172e893788a9c716d3b6868980ab8
Reviewed-on: https://chromium-review.googlesource.com/508242
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45405}
This reverts commit ce538f70c1.
Reason for revert: breaks BOM handling (thus breaking Outlook web apps).
Original change's description:
> [parser] Refactor streaming scanner streams.
>
> Unify, simplify logic, reduce UTF8 specific handling.
>
> Intend of this is also to have stream views.
> Stream views can be used concurrently by multiple threads, but
> only one thread may fetch new data from the underlying source.
> This together with unified stream view creation is intended to be
> used for parse tasks.
>
> BUG=v8:6093
>
> Change-Id: Ied8e93090c506d4735080298f0fdaeed32043915
> Reviewed-on: https://chromium-review.googlesource.com/501789
> Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45336}
TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com
BUG=v8:6093, chromium:724166
Change-Id: I022a23b8052d20d83a640c07b7864c622548bf90
Reviewed-on: https://chromium-review.googlesource.com/508888
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45404}
This patch adds HeapObject::set_map_after_allocation method that
initializes the map of the object without object layout checks.
All other map setters now check that transitions unsafe for
concurrent marking properly notify the GC.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2885883004
Cr-Commit-Position: refs/heads/master@{#45403}
Port bfa319e5d3
Original Commit Message:
We already had an optimization to turn Function.prototype.apply with
arguments object, i.e.
function foo() { return bar.apply(this, arguments); }
into a special operator JSCallForwardVarargs, which avoids the
allocation and deconstruction of the arguments object, but just passes
along the incoming parameters. We can do the same for rest parameters
and spread calls/constructs, i.e.
class A extends B {
constructor(...args) { super(...args); }
}
or
function foo(...args) { return bar(1, 2, 3, ...args); }
where we basically pass along the parameters (plus maybe additional
statically known parameters).
For this, we introduce a new JSConstructForwardVarargs operator and
generalize the CallForwardVarargs builtins that are backing this.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6407,v8:6278,v8:6344
LOG=N
Review-Url: https://codereview.chromium.org/2887153004
Cr-Commit-Position: refs/heads/master@{#45402}
Generators were previously treated as "top level" for preparsing purposes,
since all their variables are context-allocated. But doing so isn't quite
correct: the allocation of the "arguments" variable for a generator
depends on whether it's referenced, and so an inner arrow function
which references "arguments" won't properly trigger allocation of
"arguments" since the reference will not be noticed in the preparser.
The same problem exists for "this" since commit 68f0a47b28a96a4966e7b747bfa304b555e726d1;
before that commit, all generators implicitly referenced their "this" argument
as part of the desugaring. With that implicit reference gone, "this"
falls into the same problem as arguments.
This patch restricts the special "top level" treatment to modules,
which have only a trivial "this" binding (it's always undefined), and no
arguments binding. Moreover, all code inside modules is strict, meaning
that unresolved references to "this" will also result in undefined.
R=marja@chromium.org
Bug: chromium:723132
Change-Id: I814d145fb8f3f1a65abb48e4e35595428d063051
Reviewed-on: https://chromium-review.googlesource.com/508055
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45399}
This adds a bunch of assertions to CSA, mostly about documenting and checking
parameter types.
Drive-by-change: Removed unused function.
BUG=v8:6325
Review-Url: https://codereview.chromium.org/2847923003
Cr-Commit-Position: refs/heads/master@{#45398}
Uses CheckSmi to force the switch argument to be a Smi, so that it can
be used as an input into a Switch node.
Change-Id: Ibec6beaeebc2168a3f80b86512c70a99d52f2575
Reviewed-on: https://chromium-review.googlesource.com/505621
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45397}
For additions like a+'' or ''+a where we have String feedback on the
JSAdd, we can drop the concatenation and just check that a is a valid
String already (via CheckString).
BUG=v8:6259
R=petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2894563002
Cr-Commit-Position: refs/heads/master@{#45395}
For a single deferred commands, using a jump table is overkill, so
instead simply test the token against the single entry.
Bug: v8:4280
Bug: v8:6218
Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77
Reviewed-on: https://chromium-review.googlesource.com/506153
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45393}
Restore original behavior in that strings are deduplicated in lower-case
conversion (i.e. if the string is already lower-case, the original
string is returned).
BUG=v8:6353,v8:6412
Review-Url: https://codereview.chromium.org/2891853004
Cr-Commit-Position: refs/heads/master@{#45391}
We already had an optimization to turn Function.prototype.apply with
arguments object, i.e.
function foo() { return bar.apply(this, arguments); }
into a special operator JSCallForwardVarargs, which avoids the
allocation and deconstruction of the arguments object, but just passes
along the incoming parameters. We can do the same for rest parameters
and spread calls/constructs, i.e.
class A extends B {
constructor(...args) { super(...args); }
}
or
function foo(...args) { return bar(1, 2, 3, ...args); }
where we basically pass along the parameters (plus maybe additional
statically known parameters).
For this, we introduce a new JSConstructForwardVarargs operator and
generalize the CallForwardVarargs builtins that are backing this.
BUG=v8:6407,v8:6278,v8:6344
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2890023004
Cr-Commit-Position: refs/heads/master@{#45388}
We use Schedule::EnsureDeferredCodeSingleEntryPoint as a helper for
hand-crafted builtin code, to ensure deferred code isn't entered from a
mix of deferred and non-deferred code (invariant required for hot/cold
allocation, or "splintering").
When we create a "merger" block, it may be the case that the original
block had a few phi operands. Those need to be moved as well.
This bug was uncovered by both v8:6390, and, earlier, by v8:5998. We
fixed the earlier one by authoring a the builtin to avoid the need for
EnsureDeferredCodeSingleEntryPoint. I proposed earlier an alternative
where we'd replace the Ensure... method with a Verify, and throw early
when the builtin is assembled, however, we may want to maintain the
slightly higher level DSL for authoring builtins, and perform such
graph adjustments for the lower level constraints afterwards, hence
this current CL.
Bug: v8:5998 v8:6390
Change-Id: Ia3143f7a66904fe480d8edb5b52bf915b8d185dc
Reviewed-on: https://chromium-review.googlesource.com/505264
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45387}
Port 11a211ff1b
Port 663a8ef470
Original Commit Message:
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6246,chromium:718891
LOG=N
Review-Url: https://codereview.chromium.org/2892663002
Cr-Commit-Position: refs/heads/master@{#45385}
IC system does its best to properly mark stable transition source maps
as unstable (see https://chromium-review.googlesource.com/483442)
however an already recorded map can be deprecated later and the
optimizing compiler may try to generate an elements kind transition
from the updated version of deprecated map which can "become" stable
again.
Bug: chromium:723455
Change-Id: Ic0c392f153587c3cd7c7623a3a6ea85ec72ad5bd
Reviewed-on: https://chromium-review.googlesource.com/507887
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45384}
