The constructor for TypedArray in js/typedarray.js emitted
kInvalidTypedArrayAlignment if the array offset exceeded the size of the
underlying buffer. This seems like a typo introduced in
https://codereview.chromium.org/2090353003.
The error message to be emitted instead coincides with the already existing
kInvalidDataViewOffset. The message string is independent of whether the
object in question is a DataView or a typed array, so this CL:
(1) renames kInvalidDataViewOffset to just kInvalidOffset, and
(2) uses kInvalidOffset instead of kInvalidTypedArrayAlignment for cases
when the TypedArray is constructed with an offset exceeding the buffer
size.
BUG=v8:5733
TEST=Run d8, execute "new Uint8Array(new ArrayBuffer(1),2)", see the error message mention the invalid offset 2.
Review-Url: https://codereview.chromium.org/2692753002
Cr-Commit-Position: refs/heads/master@{#43151}
This CL fixes some nits in TypeError messages, unifying the form of
kDefineDisallowed and kObjectNotExtensible to match what is used by the
majority of the other messages:
* "Cannot" vs. "Can't" -> choose "Cannot"
* "property:%" -> "property %"
* omit the full-stop at the end of the message
BUG=v8:5673
Review-Url: https://codereview.chromium.org/2686233008
Cr-Commit-Position: refs/heads/master@{#43150}
This adds support for deoptimizing into the JSConstructStub after the
receiver instantiation but before the actual constructor invocation.
Such a deoptimization point is needed for cases where instantiation
might be observed (e.g. when new.target is a proxy) and hence might
trigger a deopt.
We use this new deoptimization point for the "after" frame-state the
inliner attaches to {JSCreate} nodes being inserted when constructor
calls are being inlined.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-5638b
BUG=v8:5638
Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd
Reviewed-on: https://chromium-review.googlesource.com/440125
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43149}
We cannot skip the @@hasInstance lookup in instanceof depending on a
global protector cell, as the lookup of the property is observable
via proxies or accessors. So remove the global protector and properly
implement CSA::InstanceOf via GetPropertyStub, with an appropriate
fast-path for Function.prototype[@@hasInstance] where we call the
builtin code object directly if the function matches, skipping all
the checks from the call sequence, and also avoid the redundant
ToBoolean conversion on the result.
R=yangguo@chromium.orgTBR=ulan@chromium.org
BUG=v8:5958
Review-Url: https://codereview.chromium.org/2684033012
Cr-Commit-Position: refs/heads/master@{#43137}
Reason for revert:
Due to security issue described in review thread.
Original issue's description:
> [typedarrays] move %TypedArray%.prototype.copyWithin to C++
>
> - Removes shared InnerArrayCopyWithin JS builtin from src/js/array.js
> - Implements %TypedArray%.prototype.copyWithin as a C++ builtin, which
> relies on std::memmove rather than accessing individual eleements.
> - Fixes the case where copyWithin is invoked on a TypedArray with a
> detached buffer.
> - Add tests to ensure that +/-Infinity (for all 3 parameters) is handled correctly by the
> algorithm
>
> The C++ version gets through the benchmark more than 25000 times as
> quickly as the JS implementation.
>
> BUG=v8:5925, v8:5929, v8:4648
> R=cbruni@chromium.org, adamk@chromium.org, littledan@chromium.org
>
> Review-Url: https://codereview.chromium.org/2671233002
> Cr-Commit-Position: refs/heads/master@{#42975}
> Committed: 0f1c626d55TBR=cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org,cwhan.tunz@gmail.com,caitp@igalia.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5925, v8:5929, v8:4648
Review-Url: https://codereview.chromium.org/2693753002
Cr-Commit-Position: refs/heads/master@{#43132}
Do not allow that holey properties are defined in Array sort.
Throw a type error if the array is not extensible and there are holey
properties in the middle of the array.
BUG=v8:4888
Review-Url: https://codereview.chromium.org/2664173002
Cr-Commit-Position: refs/heads/master@{#43126}
Alternative approach to https://codereview.chromium.org/2667983004/, which
does not depend on implicit control flow changes from
https://codereview.chromium.org/2664083002
- Remove handling for `async function` from Parser::RewriteReturn(). This functionality
is moved to BytecodeGenerator::BuildAsyncReturn(). This ensures that promise resolution
is deferred until all finally blocks are evaluated fully.
- Add a new deferred command (CMD_ASYNC_RETURN), which instructs ControlScope to
generate return code using BuildAsyncReturn rather than BuildReturn.
- Parser has a new `NewReturnStatement()` helper which determines what type of return
statement to generate based on the type of function.
BUG=v8:5896, v8:4483
R=littledan@chromium.org, neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, gsathya@chromium.org
Review-Url: https://codereview.chromium.org/2685683002
Cr-Commit-Position: refs/heads/master@{#43104}
This fixes the case where the index passed to {HMaybeGrowElements} used
to derive the new capacity for the elements backing store does not fit
into Smi range. Such an overflow would fail the capacity check and cause
growing to be skipped. Subsequent keyed stores would potentially go out
of bounds.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-686427
BUG=chromium:686427
Review-Url: https://codereview.chromium.org/2686263002
Cr-Commit-Position: refs/heads/master@{#43101}
Collecting precise invocation counts need to be explicitly
enabled. Once enabled, we disable optimization (optimized
code does not increment invocation count, and may inline
callees), and make sure feedback vectors interesting for
code coverage is not garbage-collected.
R=hpayer@chromium.org, jgruber@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2686063002
Cr-Commit-Position: refs/heads/master@{#43082}
This CL includes runtime and IC parts of the tracking. It is controlled by
compile-time flag FLAG_constant_field_tracking and currently disabled.
Transition from kConst to kMutable still involves map deprecation.
BUG=v8:5495
Review-Url: https://codereview.chromium.org/2598543003
Cr-Commit-Position: refs/heads/master@{#43081}
Collect code coverage from the available invocation counts.
The granularity is at function level, and invocation counts may
be lost to GC.
Coverage::Collect returns a std::vector of Coverage::ScriptData.
Each ScriptData contains a script ID and a std::vector of
Coverage::RangeEntry.
Each RangeEntry consists of a end position and the invocation
count. The start position is implicit from the end position of
the previous RangeEntry, or 0 if it's the first RangeEntry.
R=jgruber@chromium.org
BUG=v8:5808
Review-Url: https://codereview.chromium.org/2689493002
Cr-Commit-Position: refs/heads/master@{#43072}
E.g.,
{ function lazy_inner(b = somevar) { let somevar; } }
If we don't produce the same scopes, PreParser thinks that the unresolved
variable inside the default parameter resolves into the variable declared inside
the function. Thus, it's not correctly recorded as a free variable.
One part is already done by https://codereview.chromium.org/2638333002 . But at
the laziness boundary, we still produced different scopes.
Unlike previously thought, this is also needed for lazy inner function
correctness, not only for "preparser scope analysis" (ie., skipping inner
functions).
BUG=v8:5938
Change-Id: I047cd43ef16478bb0f18d1f114845e7d1ab8c5f2
Reviewed-on: https://chromium-review.googlesource.com/439345
Commit-Queue: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43044}
Where the arguments have already been inlined, we can replace these
calls with a direct call. We have to make sure that the iteration over
the arguments is not observable.
Also factor out the large chunk of logic shared with
ReduceJSConstructWithSpread.
BUG=v8:5932
Change-Id: I6c4fac670028fbd8ca82c4474d4392231573bc49
Reviewed-on: https://chromium-review.googlesource.com/439329
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43039}
It used to require >1GB of memory which leads to flaky test failures on
machines with less memory when executing multiple variants in parallel
R=cbruni@chromium.org,ulan@chromium.org
BUG=v8:5706
Change-Id: Id8c6f49cbfa51f2d443991c1493f225810efb18f
Reviewed-on: https://chromium-review.googlesource.com/439310
Commit-Queue: Camillo Bruni <cbruni@google.com>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43038}
The testb instruction requires the REX prefix when either of its
operands uses a register with the high bit set. The existing code only
considered the register operand. In the test case the REX prefix was not
emitted because the testb instruction had the register operand RAX which
does not have the high bit set. The REX prefix was necessary though
because the memory operand used R8, which has the high bit set.
R=bmeurer@chromium.org
BUG=chromium:688876
Change-Id: Ib214bebbe75965664f2aea530e29afa95a54f44f
Reviewed-on: https://chromium-review.googlesource.com/439145
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43030}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of [parsing] Fix maybe-assigned for loop variables. (patchset #3 id:40001 of https://codereview.chromium.org/2673403003/ )
>
> Reason for revert:
> Speculative revert because of https://codereview.chromium.org/2679163002/.
>
> Original issue's description:
> > [parsing] Fix maybe-assigned for loop variables.
> >
> > Due to hoisting, the value of a 'var'-declared variable may actually change even
> > if the code contains only the "initial" assignment, namely when that assignment
> > occurs inside a loop. For example:
> >
> > let i = 10;
> > do { var x = i } while (i--):
> >
> > As a simple and very conservative approximation of this, we explicitly mark
> > as maybe-assigned any non-lexical variable whose "declaration" does not
> > syntactically occur in the function scope. (In the example above, it
> > occurs in a block scope.)
> >
> > BUG=v8:5636
> >
> > Review-Url: https://codereview.chromium.org/2673403003
> > Cr-Commit-Position: refs/heads/master@{#42989}
> > Committed: a33fcd663b
>
> TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5636
>
> Review-Url: https://codereview.chromium.org/2679263002
> Cr-Commit-Position: refs/heads/master@{#43010}
> Committed: f3ae5ccf57TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2686663002
Cr-Commit-Position: refs/heads/master@{#43013}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ )
>
> Reason for revert:
> needed for properly reverting f3ae5ccf57
>
> Original issue's description:
> > Thread maybe-assigned through the bytecodes.
> >
> > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> > bytecodes, which are emitted when reading from never-assigned context slot.
> >
> > There is a subtlety here: the slot are not immutable, the meaning is
> > actually undefined-or-hole-or-immutable.
> >
> > Review-Url: https://codereview.chromium.org/2655733003
> > Cr-Commit-Position: refs/heads/master@{#43000}
> > Committed: 17c2dd3886
>
> TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Review-Url: https://codereview.chromium.org/2680923003
> Cr-Commit-Position: refs/heads/master@{#43011}
> Committed: ece4e54a31TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2679953003
Cr-Commit-Position: refs/heads/master@{#43012}
Reason for revert:
needed for properly reverting f3ae5ccf57
Original issue's description:
> Thread maybe-assigned through the bytecodes.
>
> This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> bytecodes, which are emitted when reading from never-assigned context slot.
>
> There is a subtlety here: the slot are not immutable, the meaning is
> actually undefined-or-hole-or-immutable.
>
> Review-Url: https://codereview.chromium.org/2655733003
> Cr-Commit-Position: refs/heads/master@{#43000}
> Committed: 17c2dd3886TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2680923003
Cr-Commit-Position: refs/heads/master@{#43011}
Reason for revert:
Speculative revert because of https://codereview.chromium.org/2679163002/.
Original issue's description:
> [parsing] Fix maybe-assigned for loop variables.
>
> Due to hoisting, the value of a 'var'-declared variable may actually change even
> if the code contains only the "initial" assignment, namely when that assignment
> occurs inside a loop. For example:
>
> let i = 10;
> do { var x = i } while (i--):
>
> As a simple and very conservative approximation of this, we explicitly mark
> as maybe-assigned any non-lexical variable whose "declaration" does not
> syntactically occur in the function scope. (In the example above, it
> occurs in a block scope.)
>
> BUG=v8:5636
>
> Review-Url: https://codereview.chromium.org/2673403003
> Cr-Commit-Position: refs/heads/master@{#42989}
> Committed: a33fcd663bTBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2679263002
Cr-Commit-Position: refs/heads/master@{#43010}
This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
bytecodes, which are emitted when reading from never-assigned context slot.
There is a subtlety here: the slot are not immutable, the meaning is
actually undefined-or-hole-or-immutable.
Review-Url: https://codereview.chromium.org/2655733003
Cr-Commit-Position: refs/heads/master@{#43000}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
Due to hoisting, the value of a 'var'-declared variable may actually change even
if the code contains only the "initial" assignment, namely when that assignment
occurs inside a loop. For example:
let i = 10;
do { var x = i } while (i--):
As a simple and very conservative approximation of this, we explicitly mark
as maybe-assigned any non-lexical variable whose "declaration" does not
syntactically occur in the function scope. (In the example above, it
occurs in a block scope.)
BUG=v8:5636
Review-Url: https://codereview.chromium.org/2673403003
Cr-Commit-Position: refs/heads/master@{#42989}
For x64, ia32 and x87 we would pop the return address before the stack
overflow check. This meant the stack couldn't be unwound properly if
it was going to overflow. This CL moves the pop of the return address
to after the stack overflow check.
Also adds a regression test to check that a RangeError is thrown.
BUG=689016
Review-Url: https://codereview.chromium.org/2681643004
Cr-Commit-Position: refs/heads/master@{#42984}
This correctly marks the {JSCreate} operator as potentially throwing,
since it might trigger a property access of the 'prototype' property
during instantiation. This is observable, can throw (not kNoThrow),
might have side-effects (not kNoWrite), or even trigger a lazy deopt
event (not kNoDeopt). The inlining logic has been adapted to wire up
control projections accordingly.
Note that this does not yet take care of the "after" frame-state which
is associated with the {JSCreate} node introduced by the inliner. We
still might re-evaluate the property access upon lazy deoptimization.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-5638
BUG=v8:5638
Review-Url: https://codereview.chromium.org/2671203003
Cr-Commit-Position: refs/heads/master@{#42981}
- Removes shared InnerArrayCopyWithin JS builtin from src/js/array.js
- Implements %TypedArray%.prototype.copyWithin as a C++ builtin, which
relies on std::memmove rather than accessing individual eleements.
- Fixes the case where copyWithin is invoked on a TypedArray with a
detached buffer.
- Add tests to ensure that +/-Infinity (for all 3 parameters) is handled correctly by the
algorithm
The C++ version gets through the benchmark more than 25000 times as
quickly as the JS implementation.
BUG=v8:5925, v8:5929, v8:4648
R=cbruni@chromium.org, adamk@chromium.org, littledan@chromium.org
Review-Url: https://codereview.chromium.org/2671233002
Cr-Commit-Position: refs/heads/master@{#42975}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
TailCallRuntime currently does not seem to handle adaptor frames
correctly.
BUG=chromium:688690
Review-Url: https://codereview.chromium.org/2675133003
Cr-Commit-Position: refs/heads/master@{#42950}
