Functions that take mandatory parameters plus a number of optional
parameters, that need to be materialized as an Array are quite common.
The simplest possible case of this is essentially:
function foo(mandatory, ...args) { return args; }
Babel translates this to something like:
function foo(mandatory) {
"use strict";
for (var _len = arguments.length,
args = Array(_len > 1 ? _len - 1 : 0),
_key = 1; _key < _len; _key++) {
args[_key - 1] = arguments[_key];
}
return args;
}
The key to great performance here is to make sure that we don't
materialize the (unmapped) arguments object in this case, plus that we
have some kind of fast-path for the Array constructor and the
initialization loop.
This microbenchmark ensures that we have decent performance even in the
case where the assignment to args is polymorphic, i.e. the arguments
have seen different elements kinds, starting with FAST_HOLEY_ELEMENTS
and then FAST_HOLEY_SMI_ELEMENTS.
R=yangguo@chromium.org
BUG=v8:6262
Review-Url: https://codereview.chromium.org/2823343004
Cr-Commit-Position: refs/heads/master@{#44709}
It succeeds on my machine, at least, so marking pass/fail to avoid
unnecessary noise until the attached bug is resolved.
TBR=machenbach@chromium.org
Bug: v8:6252
Change-Id: I146eee0c464896e42058745096e929d221c04347
Reviewed-on: https://chromium-review.googlesource.com/480988
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44704}
When --harmony-strict-legacy-accessor-builtins is enabled, it brings
V8's behavior in line with the spec and more recent versions of
SpiderMonkey and JSC:
- No implicit receiver coercion
- Attempting to redefine a non-configurable property throws
Bug: v8:5070
Change-Id: I82b927538604136c0c550e19bcc606fbfea1377e
Reviewed-on: https://chromium-review.googlesource.com/478312
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44703}
What will we get:
- console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
- it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
- console calls are ~ 15% faster.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:6175
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#44353}
Committed: 55905f85d6
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Commit-Position: refs/heads/master@{#44355}
Committed: cc74ea0bc4
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Commit-Position: refs/heads/master@{#44416}
Committed: f5dc738cda
Review-Url: https://codereview.chromium.org/2785293002
Cr-Commit-Position: refs/heads/master@{#44702}
+ additional fixes uncovered by bug, and addressed remaining feedback
from original CL (https://codereview.chromium.org/2806073002/).
Note that the regression test differs slightly from the bug reported one,
in that it catches the RangeError which will eventually be thrown due
to call stack size being exceeded.
BUG=chromium:712569
Review-Url: https://codereview.chromium.org/2825073002
Cr-Commit-Position: refs/heads/master@{#44700}
This switches the parser to use token positions (i.e. {Position})
instead of stream positions (i.e. {GetPosition}) everywhere. Access to
the latter is being removed as it is unsupported when the scanner is in
rewind state anyways. This prevents "skipping" a token when seeking.
R=bradnelson@chromium.org
BUG=v8:6127
Change-Id: I9c13dd20a981061a2bccc4fb57e5c57d2a64ac5c
Reviewed-on: https://chromium-review.googlesource.com/480300
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44699}
- separated V8StackTraceImpl and AsyncStackTrace,
- V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
- V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
- async tasks are cleared with related async stacks.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2816043006
Cr-Original-Commit-Position: refs/heads/master@{#44670}
Committed: 1bca73bc83
Review-Url: https://codereview.chromium.org/2816043006
Cr-Commit-Position: refs/heads/master@{#44694}
The feature is not quite ready for getting ClusterFuzzed.
BUG=v8:5516
Change-Id: I90a42f950727c8ecf46cb2987c9a459b2ba1f5a7
Reviewed-on: https://chromium-review.googlesource.com/480400
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44693}
This fixes the de-duplication logic used when writing the deoptimizer
translation of a frame-state containing {kArgumentsElementsState}. The
object counts as a captured object and participates in the numbering of
duplicated objects.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-711166
BUG=chromium:711166
Change-Id: I4a3b892017ab8217197e5f94c1a0975d0cd6979f
Reviewed-on: https://chromium-review.googlesource.com/476631
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44692}
- Migrate make grokdump to GYP and GN
- Move code from d8 into stand-alone execution
- Add test case to ensure it's up-to-date
Review-Url: https://codereview.chromium.org/2809653003
Cr-Commit-Position: refs/heads/master@{#44687}
We can use TUPLE2 or TUPLE3 for structs that do not need special
handling by deoptimizer and compiler.
This frees up a few instance types, so that adding the next few
new structs will not cause ABI compatibility to break.
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2811183005
Cr-Commit-Position: refs/heads/master@{#44685}
This changes the message from
"method_name is not generic"
to
"method_name requires that 'this' be a primitive_name object"
BUG=v8:6206
Review-Url: https://codereview.chromium.org/2814043006
Cr-Commit-Position: refs/heads/master@{#44683}
Use Type::Array to constant-fold Array.isArray builtin based on the
value input type. Also use it to improve type based alias analysis,
where we know that stores to an object of type Array don't affect stores
to an object of type OtherObject, and vice versa.
R=jarin@chromium.org
BUG=v8:6262
Review-Url: https://codereview.chromium.org/2819583002
Cr-Commit-Position: refs/heads/master@{#44681}
No usage sites are getting the length for uncompiled functions, so we can
postpone setting the correct length until after compilation. This way we don't
need to produce and store it for skipped inner functions.
In the current implementation, getting the function length compiles it (and
users rely on it - so the feature is probably not going to go away).
BUG=v8:5516
Change-Id: Id8c9a05d2391505a6cde613841094170c9a1b808
Reviewed-on: https://chromium-review.googlesource.com/468927
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44679}
Reason for revert:
Speculative revert. Seems to block the roll:
https://codereview.chromium.org/2822983004/
Might require changing a browser test first?
Original issue's description:
> [inspector] avoid cloning of async call chains
>
> - separated V8StackTraceImpl and AsyncStackTrace,
> - V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
> - V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
> - async tasks are cleared with related async stacks.
>
> BUG=v8:6189
> R=dgozman@chromium.org
>
> Review-Url: https://codereview.chromium.org/2816043006
> Cr-Commit-Position: refs/heads/master@{#44670}
> Committed: 1bca73bc83TBR=dgozman@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6189
Review-Url: https://codereview.chromium.org/2825713002
Cr-Commit-Position: refs/heads/master@{#44678}
This rolls:
450be73..b34251f
Bug: v8:6252
Change-Id: I496f35bad1717105c8e450ce045f3e9929574e0f
Reviewed-on: https://chromium-review.googlesource.com/475652
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44672}
Currently when the module has memory specified in the compiled bytes, but with no initial memory
exported memory assigns a bogus buffer to the instance. When grow_memory is called on this buffer, it tries to patch an incorrect address.
- Fix exported memory to handle no initial memory
- Fix grow_memory to handle uninitialized buffers
BUG=chromium:710844
R=bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2820223002
Cr-Commit-Position: refs/heads/master@{#44671}
- separated V8StackTraceImpl and AsyncStackTrace,
- V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
- V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
- async tasks are cleared with related async stacks.
BUG=v8:6189
R=dgozman@chromium.org
Review-Url: https://codereview.chromium.org/2816043006
Cr-Commit-Position: refs/heads/master@{#44670}
Today, the semantics of:
WebAssembly.instantiate
and
WebAssembly.compile().then(new WebAssemblyInstance)
are subtly different, to the point where attempting the proposed
change uncovered bugs.
In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.
This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.
- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2806073002
Cr-Original-Commit-Position: refs/heads/master@{#44592}
Committed: 7829af3275
Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44669}
This flag was shipped with V8 5.7 (Chrome 57).
Bug: v8:5244
Change-Id: I044edb8d7e74ea3c84bf46ec5cf81b8ff1b7a3de
Reviewed-on: https://chromium-review.googlesource.com/477975
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44667}
- Add I16x8 Splat, ExtractLane, ReplaceLane, shift ops, Some BinOps and compare ops
- Add pshufhw, pshuflw in the assembler, disassembler
- Fix incorrect modrm for pextrw, this bug disregards the register allocated and always makes pextrw use rax.
- Fix pextrw disasm to take the 0 - 7 bits of the immediate instead of 0 - 3.
- Pextrw, pinsrw are in the assembler use 128 bit encodings, pextrw, pinsrw in the disassembler use legacy encodings, fix inconsistencies causing weird code gen when --print-code is used.
Review-Url: https://codereview.chromium.org/2767983002
Cr-Commit-Position: refs/heads/master@{#44664}
If the current context is overwritten by doing Realm.navigate(0) we
fail to delete the module embedder data from the correct current
context, because we have an handle to the old context which was
already cleaned up by calling DisposeRealm in RealmNavigate.
This patch disallows navigation to the first realm.
Bug: chromium:711165
Change-Id: I6b9d3187367dae9d1fe38c0efa361d461c94c917
Reviewed-on: https://chromium-review.googlesource.com/476970
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44656}
This reverts commit cc047635ff.
The CL was reverted due to a missing DEPS mirror.
Original issue's description:
> ARM64: Add NEON support
>
> Add assembler, disassembler and simulator support for NEON in the ARM64 backend.
>
> BUG=
>
> Review-Url: https://codereview.chromium.org/2622643005
> Cr-Commit-Position: refs/heads/master@{#44306}
BUG=
Review-Url: https://codereview.chromium.org/2812573003
Cr-Commit-Position: refs/heads/master@{#44652}
e3246ad69c
removed some redundancies in yield and yield*.
In particular:
- AsyncGeneratorRawYield becomes unnecessary, and is deleted in this CL
- Parser::RewriteYieldStar() is updated to perform the IteratorValue() algorithm as appropriate
BUG=v8:6187, v8:5855
R=rmcilroy@chromium.org, adamk@chromium.org, littledan@chromium.org, vogelheim@chromium.org
Change-Id: I05e8429b9cbd4531c330ee53a05656b90162064c
Reviewed-on: https://chromium-review.googlesource.com/471806
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44649}
Currently we count optimizations to decide to disable optimization, and
count deopts to detect this decision and allow re-enabling optimizations
after a while.
However, throwing out TurboFan OSR code and GC optimized code evictions
do not count as deopts, which means that the optimization count
increases without increasing the deopt count. This increased optimization
count disables further optimization -- which is bad, because these are
not "true" deopts -- and can stop the optimization from being re-enabled,
because the deopt count can't go high enough.
Instead, we now only ever look at deopts to disable/re-enable
optimization, and opt counts are only used for naming log files and in
tests.
Change-Id: I0c7d6be497545449a38cf952cd2f007ee51982ba
Reviewed-on: https://chromium-review.googlesource.com/468811
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44647}
This fixes the validation of "|0" annotations of call sites that are
used to indicate a "signed" return type of functions. We use lookahead
during call validation and request deferred validation as part of the
actual OR-expression. Special care has to be taken to get precedence
levels of all involved operators right.
R=clemensh@chromium.org
TEST=mjsunit/asm/call-annotation
BUG=v8:6183
Change-Id: If0586f669e7cee26a13425b0fd9f41098e852d68
Reviewed-on: https://chromium-review.googlesource.com/475871
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44639}
The condition only applies in unicode mode, where any lone surrogates
are desugared into a character class (and will not be considered in this
optimization). Non-unicode mode treats lone surrogates exactly like
any other codepoint.
BUG=chromium:711092
Review-Url: https://codereview.chromium.org/2808403006
Cr-Commit-Position: refs/heads/master@{#44638}
In eval scripts, the source code position can be 0 rather
than greater than 0.
Add regression test.
Drive-by fix: unrelated typo.
Bug: 707223
Change-Id: If52c0736daac3ad42ac6d324eb8ec5f1798f6f5a
Reviewed-on: https://chromium-review.googlesource.com/476630
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44637}
This CL implements the proposed change to show information about
WebAssembly values and call frames via the inspector interface.
Each interpreted WebAssembly frame will have two scopes: A global scope
showing information about the memory (to be extended for globals), and
a local scope showing information about parameters, local variables, and
stack values.
Names of local variables will be added later.
R=ahaas@chromium.org, yangguo@chromium.org
BUG=v8:6245,v8:5822
Change-Id: I0a35fddd0a353933c86adf62083233b08098a2c7
Reviewed-on: https://chromium-review.googlesource.com/474865
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44633}
This fixes the existing lowering of {JSGetSuperConstructor} nodes to
unconditional throws. The above operator is marked as {kNoWrite} but
runtime calls are not marked as such. Any deoptimizing operation after
the throw would not be able to find a valid {Checkpoint}. We remove the
lowering case in question.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-6248
BUG=v8:6248
Change-Id: I22c922947336254502f698b02f944cf35dd8688a
Reviewed-on: https://chromium-review.googlesource.com/476570
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44632}
When the incoming value to ChangeFloat64ToTagged is in Smi range, we
represent it as Smi instead of a HeapNumber. This addresses a range of
problems where TurboFan unnecessarily deoptimizes because an operation
learned Smi feedback in Ignition, but was then confronted with a tagged
HeapNumber in TurboFan, just because the value was also represented as
unboxed double somewhere in the meantime.
BUG=v8:6256
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2815283002
Cr-Commit-Position: refs/heads/master@{#44631}
