For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40592}
The TurboFan backends currently don't support tail-calls to CPP builtins
because the semantics of kJavaScriptCallArgCountRegister has different
semantics for stub call descriptors versus JavaScript call descriptors.
This is actually a short-coming of the backends and follow-up work will
make the backends more robust in that regard to fail hard on unsupported
constructs like that. This just disables the lowering creating such a
tail-call.
R=bmeurer@chromium.org
BUG=chromium:658691
TEST=mjsunit/regress/regress-crbug-658691
Review-Url: https://codereview.chromium.org/2447383002
Cr-Commit-Position: refs/heads/master@{#40590}
Reason for revert:
Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789
Original issue's description:
> [compiler] Properly validate stable map assumption for globals.
>
> For global object property cells, we did not check that the map on the
> previous object is still the same for which we actually optimized. So
> the optimized code was not in sync with the actual state of the property
> cell. When loading from such a global object property cell, Crankshaft
> optimizes away any map checks (based on the stable map assumption),
> leading to arbitrary memory access in the worst case.
>
> TurboFan has the same bug for stores, but is safe on loads because we
> do appropriate map checks there. However mixing TurboFan and Crankshaft
> still exposes the bug.
>
> R=yangguo@chromium.org
> BUG=chromium:659475
TBR=yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2454513003
Cr-Commit-Position: refs/heads/master@{#40582}
For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40578}
This brings the BytecodeGenerator in line with FullCodeGenerator, now that
more requests for hole checks are flowing through BuildVariableAssignment.
BUG=chromium:658528
Review-Url: https://codereview.chromium.org/2447783002
Cr-Commit-Position: refs/heads/master@{#40557}
Object.create(null) is most likely to be used for dictionary-like objects.
Hence it would be beneficial to directly create a slow-mode object and avoid
additional overhead later-on.
BUG=
Review-Url: https://codereview.chromium.org/2430273007
Cr-Commit-Position: refs/heads/master@{#40551}
This CL removes code that is now unused since the port of regexp.js has been
completed. Removed functions / classes are:
* regexp.js (GetSubstitution moved to string.js)
* RegExpConstructResult stub
* RegExpFlags intrinsic
* RegExpSource intrinsic
* RegExpInitializeAndCompile runtime function
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2448463002
Cr-Commit-Position: refs/heads/master@{#40547}
CL https://codereview.chromium.org/2177273002 changed FastNewFunctionContextStub
to take a number of slots parameter and in-doing so removed the maximum slot
count for FastNewFunctionContextStub. This made it possible to create a
closure which is larger than kMaxRegularHeapObjectSize and so can't be
allocated by FastNewFunctionContextStub.
Reintroduce FastNewFunctionContextStub::kMaxSlots (but make the limit much
larger) to ensure we call the runtime for contexts which need to be
allocated in the LO space.
BUG=chromium:655573
Review-Url: https://codereview.chromium.org/2445703002
Cr-Commit-Position: refs/heads/master@{#40541}
The test ensures that in RegExp.prototype[@@split], exec is neither
accessed too early nor too often.
BUG=v8:5339,v8:5434
Review-Url: https://codereview.chromium.org/2440413002
Cr-Commit-Position: refs/heads/master@{#40526}
When lowering JSToLength, we cannot just smash arbitrary bounds on the
Select nodes, as that will confuse the representation selection later.
Instead properly rename the input using NumberMax and NumberMin.
R=jarin@chromium.org
BUG=chromium:657478
Review-Url: https://codereview.chromium.org/2440333002
Cr-Commit-Position: refs/heads/master@{#40519}
This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.
This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.
Additionally, this CL implements the proper base + offset initialization
behavior for tables.
R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
Using uint32 to store the the number of control outputs allows WebAssembly switches to have more than 2^16 case.
BUG=v8:5531
TEST=mjsunit/regress/wasm/regression-5531
R=titzer@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2425983002
Cr-Commit-Position: refs/heads/master@{#40420}
When inlining JSCallConstruct in turbofan, receiver is initialized to model
the behaviour of constructor. When an implicit receiver is not required the
receiver value should be set to the hole value instead of undefined value.
When initializing the receiver via super calls, we check that the receiver
is the hole value.
BUG=chromium:653407
Review-Url: https://codereview.chromium.org/2424123002
Cr-Commit-Position: refs/heads/master@{#40396}
The inlined version of Array.prototype.push returned the value that was
pushed instead of the new "length" property value.
R=jarin@chromium.org
BUG=chromium:656037
Review-Url: https://codereview.chromium.org/2425903002
Cr-Commit-Position: refs/heads/master@{#40384}
There are a couple of operators that can indeed produce Float32
representation, which we might end up using in a TaggedSigned
context, so add the missing conversion (indirectly via Float64).
BUG=chromium:656275
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2421193002
Cr-Commit-Position: refs/heads/master@{#40334}
A decoder error sets builder_ to null, which causes builder_->StackCheck
to segfault.
R=titzer@chromium.org
TEST=mjsunit/regress/wasm/loop-stack-check
Review-Url: https://codereview.chromium.org/2416873002
Cr-Commit-Position: refs/heads/master@{#40271}
We accidently dropped the effect on the floor that we have for the
polymorphic map check in case of array elements access.
BUG=chromium:655004
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2411273002
Cr-Commit-Position: refs/heads/master@{#40201}
For ConsString, the left hand side must be either sequential or external
if the right hand side is empty.
R=jarin@chromium.org
BUG=chromium:654723
NOTRY=true
Review-Url: https://codereview.chromium.org/2410893003
Cr-Commit-Position: refs/heads/master@{#40192}
There were once plans to generate cross-context code with TurboFan,
however that doesn't fit into the model anymore, and so all of this
is essentially dead untested code (and thus most likely already broken
in subtle ways). With this mode still in place it would also be a lot
harder to make inlining based on SharedFunctionInfo work.
BUG=v8:2206,v8:5499
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2406803002
Cr-Commit-Position: refs/heads/master@{#40109}
- Added gating code in the module-decoder to allow SIMD code only when
it can be decoded correctly
- SIMD128 values should not be exported to JS
- Try/Catch should not be available in asmjs modules
- Trivial fixes for S128 values
BUG=chromium:648079
R=ahaas@chromium.org, titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2400863003
Cr-Commit-Position: refs/heads/master@{#40067}
This patch sets `this` to be undefined when calling resolve and reject
functions attached to the deferred.
BUG=v8:5476
Review-Url: https://codereview.chromium.org/2399053003
Cr-Commit-Position: refs/heads/master@{#40056}
The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.
R=titzer@chromium.org
BUG=chromium:651961
TEST=mjsunit/regress/wasm/regression-651961
Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
Review-Url: https://codereview.chromium.org/2386183004
Cr-Original-Commit-Position: refs/heads/master@{#39972}
Cr-Commit-Position: refs/heads/master@{#39980}
Reason for revert:
Patch problem
Original issue's description:
> [wasm] Call a runtime function for a MemorySize instruction.
>
> The implementation of MemorySize with RelocatableInt32Constants is
> problematic if MemorySize is placed close to a GrowMemory instruction in
> the code. The use of a runtime function guarantees that the order in
> which MemorySize and GrowMemory is executed is correct.
>
> R=titzer@chromium.org
> BUG=chromium:651961
> TEST=mjsunit/regress/wasm/regression-651961
>
> Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
> Cr-Commit-Position: refs/heads/master@{#39972}
TBR=titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:651961
Review-Url: https://codereview.chromium.org/2391223002
Cr-Commit-Position: refs/heads/master@{#39973}
The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.
R=titzer@chromium.org
BUG=chromium:651961
TEST=mjsunit/regress/wasm/regression-651961
Review-Url: https://codereview.chromium.org/2386183004
Cr-Commit-Position: refs/heads/master@{#39972}
This fixes a gc stress bug. We cannot rely on an ordering of
clearing of the weak cells, so we explicitly reset the weak
link to the owning instance, when finalizing a compiled
module. In turn, this serves as a reliable signal when GCs
happen while instantiating, allowing us to correctly link the
new instance.
BUG=chromium:652425
Review-Url: https://codereview.chromium.org/2393443003
Cr-Commit-Position: refs/heads/master@{#39964}
Previously, b6e9f625c1 fixed self-assignment
in parameters to throw. But it failed to deal with the case of
destructuring with defaults. This patch extends that previous approach
to always treat the end of a parameter as its initializer position,
whether it has an initializer or not.
This is the minimal change to make it easy to merge; a follow-up
will rename the field of Parameter from "initializer_end_position"
to "end_position".
BUG=v8:5454
Review-Url: https://codereview.chromium.org/2390943002
Cr-Commit-Position: refs/heads/master@{#39962}
In some (rare) cases, the context depth passed to a dynamic variable lookup can
be zero. In these cases, the fast path for the lookup (i.e. load from context or
global) can always be taken, as there is no need to search the current context.
However, with no slow path checks, the bytecode graph builder had a null
environment for the slow path, causing segfaults when this graph was built.
This patch adds a null check for the slow path environment, and skips building
the slow path if the environment is null.
BUG=chromium:652186
Review-Url: https://codereview.chromium.org/2385123002
Cr-Commit-Position: refs/heads/master@{#39949}
Currently the parameter is first parsed as a reference, and then translated into a parameter. The reference stays around though, and gets resolved to the parameter. That automatically creates a use. Now that I drop all unresolved references when we abort preparsing, that also drops the unresolved reference.
Instead, mark the variable as used when its marked as forced context allocation. That's what happens in almost all other cases.
This raises the question: does it really make sense to parse parameters this ways? It seems pretty generic, but neither fast nor memory-efficient ... Did I misunderstand something?
Just land if you think the CL looks good as is.
BUG=chromium:651613
Review-Url: https://codereview.chromium.org/2386623002
Cr-Commit-Position: refs/heads/master@{#39935}
Making new nodes inside of exception-handled blocks fiddles around with the
current environment to merge the exception paths. In particular, the current
environment pointer is mutated. This patch ensures that when we merge the fast
and slow paths of the LdaContextLookup, we actually merge the correct
environment and do not accidentally merge the exceptional environment.
BUG=chromium:651394
Review-Url: https://codereview.chromium.org/2379043002
Cr-Commit-Position: refs/heads/master@{#39878}
The module size is encoded as a HeapNumber, and needs to be
explicitly cloned.
BUG=chromium:647649
Review-Url: https://codereview.chromium.org/2347333002
Cr-Commit-Position: refs/heads/master@{#39845}
TurboFan lowering (see [0]) of ConsString creation cannot ensure that
the first part of the cons string is non-empty without introducing a phi
and negatively impacting performance.
This modifies ConsStringIterator to allow empty first parts of
ConsStrings.
BUG=v8:5440
Review-Url: https://codereview.chromium.org/2377983002
Cr-Commit-Position: refs/heads/master@{#39817}
Even after https://codereview.chromium.org/2371963002 we still did not
always store a Smi into the JSTypedArray::length field, the runtime
function %TypedArrayInitializeFromArrayLike was still storing whatever
it got from the JavaScript code, which is highly dependent on internal
decisions of the ICs and the representation selection in the optimizing
compilers, so that's pretty fragile.
R=verwaest@chromium.org
BUG=chromium:650933
Review-Url: https://codereview.chromium.org/2377943002
Cr-Commit-Position: refs/heads/master@{#39802}
The call to RegExpSubclassExec may refer to a different exec method
since splitter is newly constructed previously to the call.
BUG=v8:5351
Review-Url: https://codereview.chromium.org/2370733003
Cr-Commit-Position: refs/heads/master@{#39774}
This makes sure the {EscapeAnalysisReducer} inserts proper {TypeGuard}
nodes if the replacement node is not a subtype of the original node.
This happens predominantly for code that has been made unreachable by
type checks.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-640497
BUG=chromium:640497
Review URL: https://codereview.chromium.org/2363573003 .
Cr-Commit-Position: refs/heads/master@{#39656}
This add support for ConsString objects allocated inline to the escape
analysis pass. The raw hash field in such strings needs special handling
similar to existing raw fields. This also contains materialization code
within the deoptimizer as usual.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648737
BUG=chromium:648737
Review-Url: https://codereview.chromium.org/2357153002
Cr-Commit-Position: refs/heads/master@{#39594}
This removes an optimization from the code generator that tries to
materialize certain constants (i.e. context and closure) from the
stackframe when possible. This does not work with Harmony tail calls
which are split into several instructions. There have already been
numerous bugs in this optimization, it is too fragile in its current
form.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648539
BUG=chromium:648539
Review-Url: https://codereview.chromium.org/2357583003
Cr-Commit-Position: refs/heads/master@{#39583}
This patch ensures that variables like .new_target aren't overwritable
using with scopes. It does this by ensuring that scope analysis does
not consider with scopes (or eval scopes) for such 'synthetic variables',
similarly to how the 'this' variable was already handled.
The patch also adds a DCHECK for the dynamic parallel to this case,
replacing a previous unreachable path for a particular instance.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2353623002
Cr-Commit-Position: refs/heads/master@{#39567}
This patch uses temporaries rather than unresolved variables for
.promise and .debug_is_active. For .promise, a new field is added
to the FunctionState, similarly to .generator_object. This change
fixes a bug where .promise was locally shadowable by with, affecting
program semantics.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2359513002
Cr-Commit-Position: refs/heads/master@{#39566}
The implicit assignment to the induction variable in a ForInStatement
has been ignored by the AST loop assignment analysis. This was hidden
for cases where the parser introduced a ".for" temporary, but triggers
when the variable is declared outside the loop.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647887
BUG=chromium:647887
Review-Url: https://codereview.chromium.org/2356733002
Cr-Commit-Position: refs/heads/master@{#39551}
Crankshaft just unconditionally deoptimizes the code when the length of
a string addition result would overflow. In order to protect against
deopt loops we insert a global protector cell.
We will use the same mechanism for inlining certain string additions
into TurboFan as well, and protecting against overflow (we will also
extend this to deal with String.prototype.concat and friends once we
get there).
BUG=v8:5404
R=jarin@chromium.org,hpayer@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_msan_rel
Committed: https://crrev.com/cb19257a926a55209a6d6858ce26d51a0447ba71
Review-Url: https://codereview.chromium.org/2348293002
Cr-Original-Commit-Position: refs/heads/master@{#39511}
Cr-Commit-Position: refs/heads/master@{#39525}
Reason for revert:
Mean https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10910
Original issue's description:
> [crankshaft] Protect against deopt loops from string length overflows.
>
> Crankshaft just unconditionally deoptimizes the code when the length of
> a string addition result would overflow. In order to protect against
> deopt loops we insert a global protector cell.
>
> We will use the same mechanism for inlining certain string additions
> into TurboFan as well, and protecting against overflow (we will also
> extend this to deal with String.prototype.concat and friends once we
> get there).
>
> BUG=v8:5404
> R=jarin@chromium.org,hpayer@chromium.org
>
> Committed: https://crrev.com/cb19257a926a55209a6d6858ce26d51a0447ba71
> Cr-Commit-Position: refs/heads/master@{#39511}
TBR=hpayer@chromium.org,jarin@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5404
Review-Url: https://codereview.chromium.org/2357433002
Cr-Commit-Position: refs/heads/master@{#39518}
Crankshaft just unconditionally deoptimizes the code when the length of
a string addition result would overflow. In order to protect against
deopt loops we insert a global protector cell.
We will use the same mechanism for inlining certain string additions
into TurboFan as well, and protecting against overflow (we will also
extend this to deal with String.prototype.concat and friends once we
get there).
BUG=v8:5404
R=jarin@chromium.org,hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2348293002
Cr-Commit-Position: refs/heads/master@{#39511}
We'd like wasm regressions to live under a subfolder of the mjsunit
regression folder.
BUG=
Review-Url: https://codereview.chromium.org/2344373002
Cr-Commit-Position: refs/heads/master@{#39483}
This handles the case where generating bytecode for inlining purposes
causes a stack overflow. We just abort inlining but also need to clear
pending exceptions.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647217
BUG=chromium:647217
Review-Url: https://codereview.chromium.org/2339383002
Cr-Commit-Position: refs/heads/master@{#39448}
The semantics of the {BailoutId} representing an OSR entry point is
different between the interpreter and the full code generator. These
semantics are hard-coded in various graph builders. We need to ensure
that the correct graph builder is chosen for OSR compilations.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5380
BUG=v8:5380
Review-Url: https://codereview.chromium.org/2341663002
Cr-Commit-Position: refs/heads/master@{#39444}
This adds a regression test for a bug where {OsrPoll} instructions
within the bytecode stream ended up outside of actual loops. This has
been fixed already, by merging {OsrPoll} into the backwards branch.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645888
BUG=chromium:645888
Review-Url: https://codereview.chromium.org/2337033002
Cr-Commit-Position: refs/heads/master@{#39385}
To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor calls and normal calls (and thence, to record megamorphic call counts there as well).
BUG=
Review-Url: https://codereview.chromium.org/2325083003
Cr-Commit-Position: refs/heads/master@{#39377}
The raw pointer to the parameter_map might get stale in case of accessors present on
the arguments object.
Drive-by-fix: use nullptr instead of the_hole with isolate access.
BUG=chromium:645680
Review-Url: https://codereview.chromium.org/2332503002
Cr-Commit-Position: refs/heads/master@{#39359}
The whitelist is populated with those inline intrinsics that are lowered
in JSIntrinsicInlining and were not previously blacklisted. Thus the only
additional FrameStates this CL adds are those where the caller tries to
call the INLINE version of an intrinsic but ends up calling the RUNTIME
version instead.
R=bmeurer@chromium.org
BUG=chromium:644631
Review-Url: https://codereview.chromium.org/2331543002
Cr-Commit-Position: refs/heads/master@{#39357}
This fixes a corner-case where the bytecode was using the <new.target>
register directly without going through the local variable. The value
might be clobbered because the deoptimizer doesn't properly restore the
value. The label will causes bytecode pipeline to be flushed and hence
ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645103
BUG=chromium:645103
Review-Url: https://codereview.chromium.org/2325133002
Cr-Commit-Position: refs/heads/master@{#39306}
Before this change, the spread desugaring would naively call
`%AppendElement($R, the_hole)` and in some cases $R would have
a non-holey elements kind, putting the array into the bad state
of exposing holes to author code.
This patch avoids calling %AppendElement with a hole, instead
simply incrementing $R.length when it sees a hole in the literal
(this is safe because $R is known to be an Array). The existing
logic for elements transitions takes care of giving the array a
holey ElementsKind.
BUG=chromium:644215
Review-Url: https://codereview.chromium.org/2321533003
Cr-Commit-Position: refs/heads/master@{#39294}
This adds support to the deoptimizer to materialize ContextExtension
objects that have been de-materialized by escape analysis. This is
follow-up to the inline allocation of such objects during the create
lowering phase (i.e. JSCreateWithContext and JSCreateCatchContext).
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-644245
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2317353003
Cr-Commit-Position: refs/heads/master@{#39270}
When lowering Array.prototype.push/.pop to the fast inlined version, we
first need to ensure that all prototypes (including the Object.prototype)
are stable.
R=mvstanton@chromium.org
BUG=chromium:644689
Review-Url: https://codereview.chromium.org/2319533005
Cr-Commit-Position: refs/heads/master@{#39266}
The optimization is not correct for unsigned output types, and we the
overall complexity seems too high. We need to find a better way to
take into account the input/output type restrictions.
Also added a regression test for the unsigned output bug.
BUG=v8:5267,v8:5270,v8:5357
TBR=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2320013002
Cr-Commit-Position: refs/heads/master@{#39262}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
Review-Url: https://codereview.chromium.org/2290753003
Cr-Original-Commit-Position: refs/heads/master@{#39109}
Cr-Commit-Position: refs/heads/master@{#39230}
This adds handling of {IrOpcode::kObjectIsReceiver} nodes to the escape
status analysis. Such uses are treated as escaping for now until we add
dedicated handling to the escape analysis reducer.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-631027
BUG=chromium:631027
Review-Url: https://codereview.chromium.org/2317623003
Cr-Commit-Position: refs/heads/master@{#39205}
The constructor and new.target arguments were passed to CallConstruct in
the wrong order by BytecodeGraphBuilder, which caused subclassing to be
incorrect when optimizing from bytecode.
Also clean up some unecessary functions in interpreter.cc found while
figuring this out.
BUG=chromium:642409
Review-Url: https://codereview.chromium.org/2312103002
Cr-Commit-Position: refs/heads/master@{#39204}
This handles the case where preparation of bytecode might fail inside
Compiler::EnsureBytecode due to the underlying function being a fully
validated asm.js module. We simply bailout of bytecode preparation.
R=bradnelson@chromium.org
TEST=mjsunit/regress/regress-crbug-644111
BUG=chromium:644111
Review-Url: https://codereview.chromium.org/2309853002
Cr-Commit-Position: refs/heads/master@{#39187}
Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/9470
Original issue's description:
> Allow lexically declared "arguments" in function scope in sloppy mode.
>
> Lexically declared "arguments" in sloppy mode will throw redeclaration error
> currently, this patch fixes it by delaying the declaration of arguments until we
> fully parse parameter list and function body.
>
> BUG=v8:4577
> LOG=N
>
> Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
> Cr-Commit-Position: refs/heads/master@{#39109}
TBR=adamk@chromium.org,mythria@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4577
Review-Url: https://codereview.chromium.org/2304853002
Cr-Commit-Position: refs/heads/master@{#39115}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Review-Url: https://codereview.chromium.org/2290753003
Cr-Commit-Position: refs/heads/master@{#39109}
We use a signaling NaN to represent the hole in
FAST_HOLEY_DOUBLE_ELEMENTS backing stores, but on Intel processors, the
C++ compiler may decide to (or be forced to due to calling conventions)
use X87 registers for double values. However transfering to X87
registers automatically quietens the NaNs and there's no way to disable
this. Therefore we should just always load the hole NaN from the canonical
place identified by the address_of_hole_nan external reference instead,
which might even be more efficient in some cases.
R=jarin@chromium.org, jkummerow@chromium.org
BUG=v8:5332
Review-Url: https://codereview.chromium.org/2303643002
Cr-Commit-Position: refs/heads/master@{#39062}
When we try to further fold previously folded allocations in Crankshaft
GVN we don't properly transform the allocations involved, which causes
the mechanism to leave holes in the new/old space (and thereby violate
the iterability property of the new/old space).
BUG=chromium:621868
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2297983003
Cr-Commit-Position: refs/heads/master@{#39040}
Tail calls don't make sense from async functions and generators, as
each activation of these functions needs to make a new, distnict,
non-reused generator object. These tail calls are not required per
spec. This patch disables both syntactic and implicit tail calls
in async functions and generators.
R=neis
BUG=v8:5301,chromium:639270
Review-Url: https://codereview.chromium.org/2278413003
Cr-Commit-Position: refs/heads/master@{#38986}
This preserves the original shared code of the underlying function when
bytecode is provided. The method in question should only ensure bytecode
is present, but should avoid switching compilation tiers of the given
function. It might be that the function was fast-tracked to baseline by
inlining without going through the interpreted tier first.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-635923
BUG=chromium:635923
Review-Url: https://codereview.chromium.org/2278543002
Cr-Commit-Position: refs/heads/master@{#38866}
Don't bother using %_IsJSReceiver, which immediately gets lowered to
ObjectIsReceiver anyways (by the JSIntrinsicLowering), but requires
some complicated rewiring of effect/control chains.
R=mstarzinger@chromium.org
BUG=chromium:640369
Review-Url: https://codereview.chromium.org/2271973003
Cr-Commit-Position: refs/heads/master@{#38864}
Make use of %IsAsmWasmCode in place of Wasm.instantiateModuleFromAsm,
in order to reduce the surface area of the Wasm object,
and to focus on testing asm.js coming in via the parser.
Ignore extra CONST_LEGACY assignment introduced by the parser
when modules have the form:
(function Foo(a, b, c) {..});
This requires both a validator and AsmWasmBuilder change.
Move stdlib use collection to import time,
to reject modules that import a function, even if not used.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2264913002
Cr-Commit-Position: refs/heads/master@{#38806}
Record which asm.js stdlib members are used and add a check that NaN is actually correctly set. Other stdlib members to be added in a later change.
Also add a stdlib argument to Wasm.instantiateModuleFromAsm, in preparation for that function to be replaced by normal asm.js instantiation.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2251433002
Cr-Commit-Position: refs/heads/master@{#38760}
This fixes canonicalization of {SharedFunctionInfo} objects in the
{Compiler::GetSharedFunctionInfo} method when bytecode is preserved.
Eager compilation is only triggered when no code is present.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-638551
BUG=chromium:638551
Review-Url: https://codereview.chromium.org/2245263006
Cr-Commit-Position: refs/heads/master@{#38709}
Ensures SMI values have SMI type even if they have a dot (e.g., 1.0).
Adds SMI_WITH_DOT type to maintain this.
BUG=chromium:638134
Review-Url: https://codereview.chromium.org/2248693005
Cr-Commit-Position: refs/heads/master@{#38698}
Properly deoptimize if the left hand side of a CheckedInt32Mod is
negative and the result of the operation is zero.
R=jarin@chromium.org
BUG=v8:5286
Review-Url: https://codereview.chromium.org/2243803002
Cr-Commit-Position: refs/heads/master@{#38615}
This bug was triggered by a very specific combination:
* A context-allocated variable at script scope.
* OSR optimization.
* A scheduled breakpoint, which triggers at stack checks.
Stack checks differ from other possible breakpoint locations in that
the context (among other things) may be in a register and not on the
stack, making it impossible to recover during deoptimization. The
frame_inspector then returns undefined when asked for the context.
In GetFrameDetails, handle this case by omitting all context-allocated
variables.
BUG=v8:5279
Review-Url: https://codereview.chromium.org/2245603002
Cr-Commit-Position: refs/heads/master@{#38611}
For holey/growing keyed stores, we need to check that there are no
setters in the prototype chain and protect against changes to that
via code dependencies.
R=verwaest@chromium.org
BUG=v8:5275,v8:5276
Review-Url: https://codereview.chromium.org/2231683002
Cr-Commit-Position: refs/heads/master@{#38514}
When we compile a growing store in TurboFan, we don't pass a (native)
context to the %GrowArrayElements fallback function, as the whole logic
is actually context independent. However, that means that we need to
bailout early in case the object is a prototype, which requires context
dependent checks in the array protector code.
R=cbruni@chromium.org
BUG=chromium:635798
Review-Url: https://codereview.chromium.org/2224253003
Cr-Commit-Position: refs/heads/master@{#38491}
This fixes the runtime profiler to no longer assume that seeing an
optimized frame on the stack implies the underlying function is not
being interpreted when entered normally. This no longer holds with code
generated for OSR directly from bytecode (not installed on function).
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-632800
BUG=chromium:632800
Review-Url: https://codereview.chromium.org/2208603005
Cr-Commit-Position: refs/heads/master@{#38360}
This makes sure we prevent a tier-up for function which also have an
optimized activation of OSR code on the stack. In case the OSR code
deoptimizes, it needs the bytecode to still be around.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5262
BUG=v8:5262
Review-Url: https://codereview.chromium.org/2206363004
Cr-Commit-Position: refs/heads/master@{#38359}
We don't need to add stability dependencies on JSObject prototypes when
storing to an element, because we do the map check (and thereby guard
the elements kind) and we also properly deoptimize on holes if the array
protector is not usable.
R=verwaest@chromium.org
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2198833002
Cr-Commit-Position: refs/heads/master@{#38355}
This adds the missing lazy bailout point when defining accessor pairs
within object literals via Runtime::kDefineAccessorPropertyUnchecked.
The runtime function in question can indeed trigger a lazy deopt due
to a DependentCode::kPrototypeCheckGroup dependency.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-633585
BUG=chromium:633585
Review-Url: https://codereview.chromium.org/2207413002
Cr-Commit-Position: refs/heads/master@{#38336}
An infinite recursion can be triggered when NoSideEffectToString is
called on an error object with its name property set to itself.
BUG=633998
Review-Url: https://codereview.chromium.org/2206313002
Cr-Commit-Position: refs/heads/master@{#38325}
Avoids compiling baseline code when the function isn't able to be
optimized by crankshaft.
BUG=chromium:632289
Review-Url: https://codereview.chromium.org/2194453002
Cr-Commit-Position: refs/heads/master@{#38304}
We cannot just blindly make a representation selection for Phi or Select
based on the truncations, but we also need to consider the type of the
inputs (or actually of the Phi/Select node itself). We can only use
Word32 representation based on Word32 truncation if the inputs are
Number or Oddball, same for Float64.
R=epertoso@chromium.org
BUG=v8:5255
Review-Url: https://codereview.chromium.org/2206553002
Cr-Commit-Position: refs/heads/master@{#38241}
This makes sure we are not inserting {OsrPoll} instructions for any
statements that are not actually loops and have no back edges. Without
back edges the {BytecodeGraphBuilder} is unable to deduce loop ranges
and hence cannot construct a graph for OSR entry.
R=neis@chromium.org
TEST=mjsunit/regress/regress-5252
BUG=v8:5252
Review-Url: https://codereview.chromium.org/2200733002
Cr-Commit-Position: refs/heads/master@{#38233}
When we narrow a signed32 comparison to uint8 or uint16 representation,
we also need to change the condition to unsigned comparisons otherwise
the comparison will be done on int16/int8 which interprets the narrowed
bits wrong.
R=epertoso@chromium.org
BUG=v8:5254
Review-Url: https://codereview.chromium.org/2202803003
Cr-Commit-Position: refs/heads/master@{#38231}
Previously, the stack property was set up in JS as read-only; but since
it had a JS setter, writability was ignored and writing to stack was
possible.
This is no longer the case now that stack is either an actual data
property, or is associated with C++ accessors. Explicitly set the
property as writable to preserve old behavior.
BUG=5245
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2190313002
Cr-Commit-Position: refs/heads/master@{#38158}
In the process also inline the stub into the appropriate interpreter bytecode
handler and make sure that the context register is preserved in hand-written
assembly code that calls the stub and expects the context register to be
preserved.
BUG=608675
Review-Url: https://codereview.chromium.org/2188993003
Cr-Commit-Position: refs/heads/master@{#38132}
Objects that reside below the age mark could be on pages that have been moved
within new space. In this case mementos survived which can actually point to
already-collected allocation sites.
BUG=chromium:631050,chromium:581412
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2179033005
Cr-Commit-Position: refs/heads/master@{#38094}
When we eliminate nodes during truncation analysis that have no value
uses, we must make sure that we do not eliminate speculative number
operations that would have side effects depending on the inputs, i.e.
for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
ToNumber(y) first, so if either x or y could throw an exception during
ToNumber conversion, we must not eliminate the multiplication, even if
it has no value uses (some later pass may kill the actual machine
multiplication, but the checks on the inputs have to remain still).
So we check whether both x and y are PlainPrimitive, i.e. neither
Receiver nor Symbol, which could raise exceptions for ToNumber, and
only in that case we propagate the "unusedness" of the node to its
inputs.
This also uncovered a bug with the type of Dead, which must be None,
as this represents an impossible value, so we had to fix that too.
Also the dead code removal will not work correctly for constants (i.e.
pure nodes with no value inputs), as those might be cached and hence
we might resurrect them for an unrelated node lowering during
SimplifiedLowering and only later kill the actual node (replacing its
uses with Dead), which would then also replace the new use with Dead.
So that was fixed as well. This shouldn't change anything for the
result, as unused constants automagically disappear from the graph later
on anyways.
R=yangguo@chromium.org
BUG=chromium:631318
Review-Url: https://codereview.chromium.org/2182003002
Cr-Commit-Position: refs/heads/master@{#38038}
Introducing machine operators early causes trouble for the typing,
truncation analysis and representation selection, so we should rather
stick to simplified operators instead. Now there's only the for-in case
left, which is not clear how we can handle this in a better way.
Drive-by-fix: Also don't introduce Int32Constant and Word32Shl in
JSTypedLowering, but use NumberConstant and proper NumberShiftLeft
operators instead.
R=jarin@chromium.org
BUG=chromium:630951
Review-Url: https://codereview.chromium.org/2182453002
Cr-Commit-Position: refs/heads/master@{#38008}
The dead code elimination in SimplifiedLowering can eliminate pure nodes
if they don't have value uses. But some of those can indeed have control
inputs, i.e. Phi nodes do of course have a control input.
R=jarin@chromium.org
BUG=chromium:630923
Review-Url: https://codereview.chromium.org/2177133002
Cr-Commit-Position: refs/heads/master@{#37995}
In PrependElementIndicesImpl we sort a FixedArray of indices potentially
containing HeapNumbers. During the string conversion we might trigger a GC.
This in turn might try to read a slot where we previously had a HeapNumber
but the sort sneaked a SMI in there which is not a valid pointer.
BUG=chromium:630561
Review-Url: https://codereview.chromium.org/2173653003
Cr-Commit-Position: refs/heads/master@{#37993}
This is in preparation to implementing exception prediction for async
functions. Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.
To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.
The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2161263003
Cr-Commit-Position: refs/heads/master@{#37966}
The optimizing compilers actually invoke %TransitionElementsKind for
any kind of JSObject, the only relevant thing is the elements kind.
The runtime function was however checking for JSArray unnecessarily.
This only worked by coincindence in Crankshaft because the stub would
normally not call into the runtime fallback.
R=jarin@chromium.org
BUG=chromium:629823
Review-Url: https://codereview.chromium.org/2166963004
Cr-Commit-Position: refs/heads/master@{#37919}
This ports a large portion of Error methods to C++,
including the constructor, stack setter and getter,
and Error.prototype.toString.
BUG=
Review-Url: https://codereview.chromium.org/2142933003
Cr-Commit-Position: refs/heads/master@{#37870}
We need to pay attention to potential side effects from parameter
evaluation when inlining the fast case Array.prototype.shift.
R=yangguo@chromium.org
BUG=chromium:614644
Review-Url: https://codereview.chromium.org/2161943002
Cr-Commit-Position: refs/heads/master@{#37850}
The bug occurs because we do not canonicalize character class ranges
before adding case equivalents. While adding case equivalents, we abort
early for one-byte subject strings, assuming that the ranges are sorted.
Which they are not.
R=marja@chromium.org
BUG=v8:5199
Review-Url: https://codereview.chromium.org/2159683002
Cr-Commit-Position: refs/heads/master@{#37833}
This fixes the deoptimization information for the lazy bailout point
after a [[ToObject]] operation inserted for with statements. The result
value was pushed on the operand stack but erroneously ignored and left
on the operand stack by the FullCodeGenerator.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-5205
BUG=v8:5205
Review-Url: https://codereview.chromium.org/2158443002
Cr-Commit-Position: refs/heads/master@{#37818}
Using the Hydrogen code stub bailout mechanism is not correct for the
string length overflow check in the StringAddStub. Instead make sure we
just throw the proper exception.
R=mstarzinger@chromium.org
BUG=chromium:627934
Review-Url: https://codereview.chromium.org/2146353002
Cr-Commit-Position: refs/heads/master@{#37758}
This adds a missing conversion of time zone names to string primitives
before case conversion and regular expression matching are applied.
This is in sync with ECMA-402, section 12.1.1.1, step 16(a).
R=jochen@chromium.org
TEST=mjsunit/regress/regress-crbug-627935
BUG=chromium:627935
Review-Url: https://codereview.chromium.org/2143003005
Cr-Commit-Position: refs/heads/master@{#37757}
This fixes the deoptimization information for the lazy bailout point
after a [[ToName]] operation inserted for object literals and class
literals. The result value was erroneously ignored.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-627828
BUG=chromium:627828
Review-Url: https://codereview.chromium.org/2149493003
Cr-Commit-Position: refs/heads/master@{#37719}
Collect type feedback in the call bytecode handler. The current
implementation only collects feedback for JS function objects. The other
objects and Array functions do not collect any feedback. They will be
marked Megamorphic.
BUG=v8:4280, v8:4780
LOG=N
Review-Url: https://codereview.chromium.org/2122183002
Cr-Commit-Position: refs/heads/master@{#37700}
- check that packed elements do not contain the_hole (with fix)
- verify argument objects with elements kind
- use JSObjectVerifiy in all JSObject "subclasses"
- change initialization order for ArrayLiteralBoilerplate to simplify verification
BUG=v8:5188
Review-Url: https://codereview.chromium.org/2126613002
Cr-Commit-Position: refs/heads/master@{#37680}
CallSite::IsConstructor() was unable to recognize builtin construct stubs
(NumberConstructor_ConstructStub and StringConstructor_ConstructStub) as
constructors, and thus these frames were not formatted correctly in stack
traces.
Fix this by explicitly marking their Code objects as construct stubs and
passing along a special receiver value when we encounter such cases in
CaptureSimpleStackTrace.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2125163004
Cr-Commit-Position: refs/heads/master@{#37631}
For variables introduced as part of a catch pattern, we used to set their
"initializer position" to the beginning of the pattern. This lead to
full-codegen eliminating crucial hole checks when reading such variables
inside the pattern itself.
R=adamk@chromium.org, littledan@chromium.org
BUG=v8:5178
Review-Url: https://codereview.chromium.org/2123953002
Cr-Commit-Position: refs/heads/master@{#37569}
While the test was useful to reproduce the issue locally it creates a lot of
heap pressure and causes all sorts of troubles (OOM, slowness) on the bots, so
let's drop it.
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2127803002
Cr-Commit-Position: refs/heads/master@{#37551}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=yangguo@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2053573004
Cr-Commit-Position: refs/heads/master@{#37545}
This is a quick fix for the hole leaking from generators via the debugger's frame
inspection feature: when collecting the arguments, convert each hole to undefined.
In the long term, we probably want to remember and restore the actual arguments
rather than pushing these dummy arguments on each resume.
BUG=v8:5164
Review-Url: https://codereview.chromium.org/2122923003
Cr-Commit-Position: refs/heads/master@{#37544}
The dependency would only happen if we have a smi overflow for the length and
have create a heap number. In this case the heap number would've to survive
until the array buffer is collected.
To avoid this dependency we track the length (as we previously used to).
BUG=chromium:625752
LOG=N
TEST=test/mjsunit/regress/regress-625752.js
R=hpayer@chromium.org
This reverts commit 1791d7bb9a.
Review-Url: https://codereview.chromium.org/2127643002
Cr-Commit-Position: refs/heads/master@{#37537}
Reason for revert:
[Sheriff] This makes mjsunit/regress/regress-625752 extremely slow on all gc stress bots and leads to timeouts with custom snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/6602
Original issue's description:
> [heap] Track length for array buffers to avoid free-ing dependency
>
> The dependency would only happen if we have a smi overflow for the length and
> have create a heap number. In this case the heap number would've to survive
> until the array buffer is collected.
>
> To avoid this dependency we track the length (as we previously used to).
>
> BUG=chromium:625748,chromium:625752
> LOG=N
> TEST=test/mjsunit/regress/regress-625752.js
> R=hpayer@chromium.org
>
> Committed: https://crrev.com/ddc75cc1356a58b6cfd63f9da0586e1150496b3d
> Cr-Commit-Position: refs/heads/master@{#37530}
TBR=hpayer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:625748,chromium:625752
Review-Url: https://codereview.chromium.org/2127483003
Cr-Commit-Position: refs/heads/master@{#37533}
The dependency would only happen if we have a smi overflow for the length and
have create a heap number. In this case the heap number would've to survive
until the array buffer is collected.
To avoid this dependency we track the length (as we previously used to).
BUG=chromium:625748,chromium:625752
LOG=N
TEST=test/mjsunit/regress/regress-625752.js
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2122603004
Cr-Commit-Position: refs/heads/master@{#37530}
This concerns formatting of calls to, e.g., Math.acos in stack traces,
in which the receiver is an object with an attached toString tag. If
such a tag exists, use it to format the receiver typename to ensure that
the stack trace includes 'Math.acos' instead of 'Object.acos'.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2110683007
Cr-Commit-Position: refs/heads/master@{#37513}
Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).
This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106883003
Cr-Commit-Position: refs/heads/master@{#37500}
This patch implements "immutable prototype exotic objects" from the ECMAScript
spec, which are objects whose __proto__ cannot be changed, but are not otherwise
frozen. They are introduced in order to prevent a Proxy from being introduced
to the prototype chain of the global object.
The API is extended by a SetImmutablePrototype() call in ObjectTemplate, which
can be used to vend new immutable prototype objects. Additionally, Object.prototype
is an immutable prototype object.
In the implementation, a new bit is added to Maps to say whether the prototype is
immutable, which is read by SetPrototype. Map transitions to the immutable prototype
state are not saved in the transition tree because the main use case is just for
the prototype chain of the global object, which there will be only one of per
Context, so no need to take up the extra word for a pointer in each full transition
tree.
BUG=v8:5149
Review-Url: https://codereview.chromium.org/2108203002
Cr-Commit-Position: refs/heads/master@{#37482}
This makes the elimination of checkpoints flowing effect-wise into nodes
having the {Return} operator more permissive. We can cut out checkpoints
even when they are not wholly owned by the return. This also alleviates
a problem where TCO no longer applies.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-624747
BUG=chromium:624747
Review-Url: https://codereview.chromium.org/2118793002
Cr-Commit-Position: refs/heads/master@{#37480}
This ensures no eager bailout point is emitted after a comma expression
in test context where the right-hand side omitted an eager bailout point
as well. This is to stay in sync with full-codegen.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-624919
BUG=chromium:624919
Review-Url: https://codereview.chromium.org/2113893004
Cr-Commit-Position: refs/heads/master@{#37475}
This turns the blacklist back into a white-list adding all binary operations as allowed operations. The one known fix is that it forces canonicalization of the double-hole as double constant.
BUG=chromium:621147
Review-Url: https://codereview.chromium.org/2106393002
Cr-Commit-Position: refs/heads/master@{#37452}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}
Previously, any expressions inside destructuring patterns in a catch
would be parsed in the surrounding scope, instead of in the catch's
scope. This change fixes that by entering not only the catch scope,
but also the block scope inside it.
R=neis@chromium.org
BUG=v8:5106, v8:5112
Review-Url: https://codereview.chromium.org/2110193002
Cr-Commit-Position: refs/heads/master@{#37415}
Reason for revert:
Looks like this breaks on nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/7626
Original issue's description:
> [builtins] New frame type for exits to C++ builtins
>
> Prior to this commit, calls to C++ builtins created standard exit
> frames, which are skipped when constructing JS stack traces. In order to
> show these calls on traces, we introduce a new builtin exit frame type.
>
> Builtin exit frames contain target and new.target on the stack and are
> not skipped during stack trace construction.
>
> BUG=v8:4815
> R=bmeurer@chromium.org, yangguo@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
> Cr-Commit-Position: refs/heads/master@{#37384}
TBR=yangguo@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106113002
Cr-Commit-Position: refs/heads/master@{#37394}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review-Url: https://codereview.chromium.org/2090723005
Cr-Commit-Position: refs/heads/master@{#37384}
The lastIndex property must be written with the semantics of a strict [[Set]],
so an exception must be thrown when the attributes don't allow writing. We used
to ignore the attributes.
R=littledan@chromium.org, yangguo@chromium.org
BUG=v8:5138
Review-Url: https://codereview.chromium.org/2109593002
Cr-Commit-Position: refs/heads/master@{#37369}
Comparisons were allowing asm 'int' values in places
that require strict 'signed' or 'unsigned' but not both.
Fixes crash when these make it to asm-wasm.
BUG=599413
BUG=v8:4203
R=aseemgarg@chromium.org
Review-Url: https://codereview.chromium.org/2106683003
Cr-Commit-Position: refs/heads/master@{#37353}
We were not checking that the string passed to instantiateFromAsm
contains a function declaration (any declaration was allowed).
Fixes crash.
BUG=620649
BUG=v8:4203
R=aseemgarg@chromium.org
Review-Url: https://codereview.chromium.org/2109533002
Cr-Commit-Position: refs/heads/master@{#37349}
When re-scoping arrow function parameter initializers, temporaries
should be moved from the closure of the old scope to the closure of
the new scope, if necessary.
R=adamk@chromium.org, rossberg@chromium.org
BUG=chromium:622663
LOG=N
Review-Url: https://codereview.chromium.org/2083083007
Cr-Commit-Position: refs/heads/master@{#37335}
This adds a missing lazy bailout point when defining data properties
with computed property names in object literals. The runtime call to
Runtime::kDefineDataPropertyInLiteral can trigger deopts. The necessary
bailout ID already exists and is now properly used.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-621816
BUG=chromium:621816
Review-Url: https://codereview.chromium.org/2099133003
Cr-Commit-Position: refs/heads/master@{#37294}
While we properly handled scopes of initializers in destructured parameters,
we never did the right thing for computed properties. This patch fixes that
by factoring out PatternRewriter's scope rewriting logic and calls it
for the computed property case.
BUG=chromium:620119
Review-Url: https://codereview.chromium.org/2084103002
Cr-Commit-Position: refs/heads/master@{#37228}
Reason for revert:
Infra issue appears to be over
TBR=adamk@chromium.org
Original issue's description:
> Revert of Rewrite scopes of non-simple default arguments (patchset #5 id:80001 of https://codereview.chromium.org/2077283004/ )
>
> Reason for revert:
> Seems to close tree (but it could be an infra issue)
>
> Original issue's description:
> > Rewrite scopes of non-simple default arguments
> >
> > Default parameters have additional declaration block scopes inserted
> > around them when something in the function scope calls eval. This
> > patch sets the parent scope of the expressions introduced due to
> > those defaults to the new block scope.
> >
> > R=adamk
> > BUG=chromium:616386
> >
> > Committed: https://crrev.com/0e14baf712955a1993f742647bb2adc293702b80
> > Cr-Commit-Position: refs/heads/master@{#37198}
>
> TBR=adamk@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:616386
>
> Committed: https://crrev.com/dd50262933d2ac087da32be887a7c18385fd998e
> Cr-Commit-Position: refs/heads/master@{#37201}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2086353003
Cr-Commit-Position: refs/heads/master@{#37202}
Reason for revert:
Seems to close tree (but it could be an infra issue)
Original issue's description:
> Rewrite scopes of non-simple default arguments
>
> Default parameters have additional declaration block scopes inserted
> around them when something in the function scope calls eval. This
> patch sets the parent scope of the expressions introduced due to
> those defaults to the new block scope.
>
> R=adamk
> BUG=chromium:616386
>
> Committed: https://crrev.com/0e14baf712955a1993f742647bb2adc293702b80
> Cr-Commit-Position: refs/heads/master@{#37198}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2081323006
Cr-Commit-Position: refs/heads/master@{#37201}
Default parameters have additional declaration block scopes inserted
around them when something in the function scope calls eval. This
patch sets the parent scope of the expressions introduced due to
those defaults to the new block scope.
R=adamk
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2077283004
Cr-Commit-Position: refs/heads/master@{#37198}
Failing to do the right check in AdvancePage results in a crash in a CHECK later
in EnsureCurrentCapacity.
BUG=chromium:620750,chromium:622115
LOG=N
R=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2090013002
Cr-Commit-Position: refs/heads/master@{#37171}
Reland of https://codereview.chromium.org/2048703002/
Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
(this caused a test262 failure.). However, the code `eval("function NaN() {}");`
should actually throw a TypeError. This patch changes most cases of
redeclaration errors from TypeError to SyntaxError. See the test
mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
references.
The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
ES#sec-evaldeclarationinstantiation
BUG=v8:4955
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
R=adamk
Review-Url: https://codereview.chromium.org/2086063002
Cr-Commit-Position: refs/heads/master@{#37156}
We need to trim the graph before we execute the MemoryOptimizer, because
that just walks the effect chain from Start to End and cannot deal with
dead nodes in the use lists.
R=jarin@chromium.org
BUG=chromium:614292
Review-Url: https://codereview.chromium.org/2080703003
Cr-Commit-Position: refs/heads/master@{#37133}
While the EcmaScript specification doesn't define precise values for the
Math constants or the Math functions, we should at least ensure that the
values of the constants and the functions agree, i.e. Math.E should be
exactly the same value as Math.exp(1).
Also make sure that Math.exp(1) returns the expected value; we should
revisit the fdlibm algorithm and figure out why it's wrong in the last
bit.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:626111,v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2079233005
Cr-Commit-Position: refs/heads/master@{#37128}
This adds a new BUILTIN frame type, which supports variable number of
arguments for builtins implemented in hand-written native code (we will
extend this mechanism to TurboFan builtins at some point). Convert the
Math.max and Math.min builtins to construct a BUILTIN frame if required.
This does not yet work for C++ builtins, but that'll be the next step.
R=bmeurer@chromium.org, jarin@chromium.org
BUG=v8:4815
LOG=n
Review-Url: https://codereview.chromium.org/2069423002
Cr-Commit-Position: refs/heads/master@{#37051}
This makes sure exception reporting done by the debug shell behaves
gracefully even near the stack limit. When line number determination
fails we just fallback to not printing source information.
R=yangguo@chromium.org
TEST=mjsunit/regress/regress-crbug-620253
BUG=chromium:620253
Review-Url: https://codereview.chromium.org/2069543007
Cr-Commit-Position: refs/heads/master@{#37031}
Reason for revert:
As discussed offline with Toon, this is not the correct fix here.
Original issue's description:
> [turbofan] Properly handle dictionary maps in the prototype chain.
>
> Dictionary prototypes don't have stable maps, but still don't matter for
> element access. Generalized the JSNativeContextSpecialization a bit to
> handle everything that Crankshaft can handle in this regard.
>
> R=jarin@chromium.org
> BUG=chromium:616709
>
> Committed: https://crrev.com/1c7bdc7f6f4d9512f4982590bd949f265ee9c8c3
> Cr-Commit-Position: refs/heads/master@{#37019}
TBR=jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2076493002
Cr-Commit-Position: refs/heads/master@{#37029}
Dictionary prototypes don't have stable maps, but still don't matter for
element access. Generalized the JSNativeContextSpecialization a bit to
handle everything that Crankshaft can handle in this regard.
R=jarin@chromium.org
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2067423003
Cr-Commit-Position: refs/heads/master@{#37019}
This is to make sure the test in question does not run out of stack
space during bootstrapping on any configuration. Our fuzzers take the
test an run it against a broad spectrum of configuration. The new size
of 100 is used throughout our test suite as "the smallest" stack size.
R=jkummerow@chromium.org
TEST=mjsunit/regress/regress-1132
BUG=chromium:619744
Review-Url: https://codereview.chromium.org/2068993002
Cr-Commit-Position: refs/heads/master@{#36995}
Reason for revert:
This is going to break the LayoutTest inspector-protocol/console/console-let-const-with-api.html as seen in https://build.chromium.org/p/tryserver.v8/builders/v8_linux_blink_rel/builds/2247 . Please run this test manually, using instructions at https://www.chromium.org/developers/testing/webkit-layout-tests , and fix on the Chrome side if needed before resubmitting this patch.
Original issue's description:
> change most cases of variable redeclaration from TypeError to SyntaxError.
>
> Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
> (this caused a test262 failure.). However, the code `eval("function NaN() {}");`
> should actually throw a TypeError. This patch changes most cases of
> redeclaration errors from TypeError to SyntaxError. See the test
> mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
> references.
>
> The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
> ES#sec-evaldeclarationinstantiation
>
> BUG=v8:4955
> LOG=y
>
> Committed: https://crrev.com/2b787561763d0f7e8dab698652715a742cf78291
> Cr-Commit-Position: refs/heads/master@{#36940}
TBR=adamk@chromium.org,jwolfe@igalia.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4955
Review-Url: https://codereview.chromium.org/2064793002
Cr-Commit-Position: refs/heads/master@{#36941}
Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
(this caused a test262 failure.). However, the code `eval("function NaN() {}");`
should actually throw a TypeError. This patch changes most cases of
redeclaration errors from TypeError to SyntaxError. See the test
mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
references.
The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
ES#sec-evaldeclarationinstantiation
BUG=v8:4955
LOG=y
Review-Url: https://codereview.chromium.org/2048703002
Cr-Commit-Position: refs/heads/master@{#36940}
This fixes FastNewStrictArgumentsStub and FastNewRestParameterStub to no
longer assume that the strict arguments object being allocated will fit
into new-space. The case where said object needs to move to large object
space is now handled in the runtime.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-614727
BUG=chromium:614727
Review-Url: https://codereview.chromium.org/2054853002
Cr-Commit-Position: refs/heads/master@{#36917}
Only look at the --ignition-generators flag when determining whether to use
Ignition (in compiler.cc). In generator runtime functions, instead of looking
at the flag, determine the generator kind based on whether the generator has a
bytecode array. This allows compiling some generator function using
full-codegen and others using Ignition, e.g when using --ignition-filter.
R=mstarzinger@chromium.org
BUG=chromium:618657,v8:4907
Review-Url: https://codereview.chromium.org/2052873002
Cr-Commit-Position: refs/heads/master@{#36864}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=bmeurer@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2045193002
Cr-Commit-Position: refs/heads/master@{#36852}
When walking up the prototype chain during OrdinaryHasInstance, we first
check if the current prototype equals the expected one, and only
afterwards check the current prototype against null. That's obviously
wrong if we check something like Proxy, whose prototype is null.
R=yangguo@chromium.org
BUG=v8:5085
Review-Url: https://codereview.chromium.org/2041103007
Cr-Commit-Position: refs/heads/master@{#36840}
Adding properties to prototypes is faster when we don't force their
maps into fast mode yet. Once a prototype shows up in the IC system,
its setup phase is likely over, and it makes sense to transition it
to fast properties.
This patch speeds up the microbenchmark in the bug by 20x.
Octane-Typescript sees a 3% improvement.
BUG=chromium:607010
Review-Url: https://codereview.chromium.org/2036493006
Cr-Commit-Position: refs/heads/master@{#36828}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=verwaest@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2041353003
Cr-Commit-Position: refs/heads/master@{#36815}
This makes sure {NodeProperties::FindFrameStateBefore} can deal with
effect chains that are marked as dead. This can happen when reducers
looking for frame states run together with other reducers killing some
execution paths within the same reduction phase.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-617567
BUG=chromium:617567,chromium:617224
Review-Url: https://codereview.chromium.org/2041833002
Cr-Commit-Position: refs/heads/master@{#36743}
Introduce a dedicated Float64Log machine operator, that is either
implemented by a direct C call or by platform specific code, i.e.
using the FPU on x64 and ia32.
This operator is used to implement Math.log as a proper TurboFan
builtin on top of the CodeStubAssembler.
Also introduce a NumberLog simplified operator on top of Float64Log
and use that for the fast inline path of Math.log inside TurboFan
optimized code.
BUG=v8:5065
Review-Url: https://codereview.chromium.org/2029413005
Cr-Commit-Position: refs/heads/master@{#36703}
This CL also updates the elements kind transition lookup logic:
1) First we go back to the root map,
2) Follow elements kind transitions,
3) Replay the property transitions.
BUG=v8:5009
LOG=Y
TBR=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2015513002
Cr-Commit-Position: refs/heads/master@{#36652}
Reason for revert:
Triggers crashes on the deopt fuzzer:
https://build.chromium.org/p/client.v8/builders/V8%20Deopt%20Fuzzer/builds/10608
Repro:
out/Release/d8 --test --random-seed=849179141 --deopt-every-n-times 149 --nohard-abort --nodead-code-elimination --nofold-constants --noconcurrent-recompilation test/webkit/resources/standalone-pre.js test/webkit/dfg-arguments-mixed-alias.js test/webkit/resources/standalone-post.js
Original issue's description:
> [crankshaft] Only exclude explicit 'arguments' (and 'this') from liveness analysis.
>
> Currently, we do not emit EnvironmentMarkers if the hydrogen value
> in the environment is arguments object. As the hydrogen value can change
> for local variables, we emit only some environment markers. That can
> cause environment liveness analysis to mark part of live range as live
> and part as dead. The zapping phase then only inserts zaps in
> live->dead transitions, potentially zapping a live value.
>
> With this CL, we only emit EnvironmentMarkers for 'this' and
> 'arguments' local variables, disregarding the hydrogen value.
>
> BUG=chromium:612146
> LOG=n
>
> Committed: https://crrev.com/1428fbe224dc2df0cb6f59e4959430f7aa614064
> Cr-Commit-Position: refs/heads/master@{#36641}
TBR=jkummerow@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:612146
Review-Url: https://codereview.chromium.org/2029563002
Cr-Commit-Position: refs/heads/master@{#36644}
Currently, we do not emit EnvironmentMarkers if the hydrogen value
in the environment is arguments object. As the hydrogen value can change
for local variables, we emit only some environment markers. That can
cause environment liveness analysis to mark part of live range as live
and part as dead. The zapping phase then only inserts zaps in
live->dead transitions, potentially zapping a live value.
With this CL, we only emit EnvironmentMarkers for 'this' and
'arguments' local variables, disregarding the hydrogen value.
BUG=chromium:612146
LOG=n
Review-Url: https://codereview.chromium.org/2026173003
Cr-Commit-Position: refs/heads/master@{#36641}
When we moved the String.fromCharCode builtin to C++, we slightly
regressed the fast single character code argument case. Recovered some
of the performance by implementing the builtin using the TurboFan
CodeStubAssembler.
Drive-by-fix: Make sure the stack trace from the implicit ToNumber
conversion in String.fromCharCode includes the builtin by adding a
regression test for that.
R=yangguo@chromium.org
BUG=chromium:609831,chromium:613947,v8:5049
Review-Url: https://codereview.chromium.org/2021143003
Cr-Commit-Position: refs/heads/master@{#36611}
Rewrite decodeURI and decodeURIComponent as builtin functions
and install them in the bootstrapper.
Delete unused runtime functions:
- TruncateString
- NewString
- OneByteSeqStringGetChar
- OneByteSeqStringSetChar
- TwoByteSeqStringGetChar
- TwoByteSeqStringSetChar
Add regression test for decoding large strings. Clusterfuzz detected
a problem with %TruncateString, see
https://bugs.chromium.org/p/chromium/issues/detail?id=612109#c6
This is automatically fixed by this rewrite because %TruncateString
is deleted anyways.
Crude benchmark on 585 decodeURI and decodeURIComponent tests
averaged over five runs:
* builtin functions
real 0m9.69s
user 2m39.8816s
sys 0m12.6398s
* JS functions calling into the runtime e.g., for %TruncateString
real 0m11.0598s
user 3m6.7026s
sys 0m13.5756s
By running:
$ time tools/run-tests.py --arch=x64 --mode=Release --buildbot
test262/built-ins/decodeURI* mjsunit/uri
>>> Running tests for x64.Release
BUG=v8:4912, chromium:612109
R=yangguo@chromium.org, bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/1994733003
Cr-Commit-Position: refs/heads/master@{#36543}
Removes the DONT_DELETE enum bit from the properties to make them
configurable.
Also, updates the regress-typedarray-length test to --
- Check for true boolean return value on deletion of these
properties.
- Check for undefined return value on trying to access these
properties after deletion.
BUG=v8:4902
LOG=Y
Review-Url: https://codereview.chromium.org/2001393004
Cr-Commit-Position: refs/heads/master@{#36528}
This makes sure the deoptimizer can materialize sloppy arguments objects
with the FAST_SLOPPY_ARGUMENTS_ELEMENTS elements kind. TurboFan's escape
analysis treates those as normal JSObject types and hence materializes
them differently than Crankshaft does.
R=verwaest@chromium.org
TEST=mjsunit/regress/regress-crbug-613919
BUG=chromium:613919
Review-Url: https://codereview.chromium.org/2001133002
Cr-Commit-Position: refs/heads/master@{#36440}
This makes escape analysis skip analyzing the code entry field within
JSFunction objects. Said field is an untagged pointer field and hence
cannot be tracked by an ObjectState node.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-613494
BUG=chromium:613494
Review-Url: https://codereview.chromium.org/1997353002
Cr-Commit-Position: refs/heads/master@{#36436}
The previous JavaScript version created way too many ConsStrings for
longer strings, i.e. when using String.fromCharCode together with
Function.prototype.apply and arrays of char codes.
This version now always allocates sequential strings and therefore uses
way less memory when turning longer character sequences into strings,
and therefore fixes the memory regression on Google Maps.
BUG=chromium:609831
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2004733002
Cr-Commit-Position: refs/heads/master@{#36427}
In VisitArrayLiteral(), we stopped creating boilerplates during
compilation. This created a bug, because we'd emit an HStoreKeyed with an
ElementsKind based on the initial elements kind of the boilerplate. Since
boilerplates may transition as part of elements transition feedback, this can
lead to incorrect values (storing a smi in a double array).
BUG=chromium:606021
Review-Url: https://codereview.chromium.org/2000673002
Cr-Commit-Position: refs/heads/master@{#36408}
In ES2015, the "byteLength" and "byteOffset" properties of DataViews are
getters on the prototype, so the previously-used strategy of special-casing
them using only the receiver map is invalid.
A future CL will need to use the same strategy which will be taken for
TypedArray "length", "byteLength", and "byteOffset": adding a prototype
chain check.
BUG=v8:5018, chromium:593634
Review-Url: https://codereview.chromium.org/1984043002
Cr-Commit-Position: refs/heads/master@{#36382}
This promotes the escape analysis from an experimental feature to be a
fully supported feature. The main goal is to unleach ClusterFuzz on the
implementation so that we can stabilize it.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1989833002
Cr-Commit-Position: refs/heads/master@{#36324}
These guards are useless anyways once you make it throw the
effect/control linearizer because all memory operations and
calls are connected to the control and/or effect chain anyways
afterwards.
Drive-by-fix: Fail in the InstructionSelector if we ever see
a Guard node.
R=jarin@chromium.org
BUG=chromium:612142
Review-Url: https://codereview.chromium.org/1980383002
Cr-Commit-Position: refs/heads/master@{#36302}
This makes escape analysis treat all guard nodes in the graph as an
escaping use. We eventually want to properly handle guard nodes, this
just serves as a temporary workaround to get things going.
R=bmeurer@chromium.org
BUG=v8:602595
LOG=n
Review-Url: https://codereview.chromium.org/1972323004
Cr-Commit-Position: refs/heads/master@{#36286}
This reverts commit 41d571dfe8.
Reason for revert: This patch breaks the correctness of the typedarray
properties such as length, byteOffset, byteLength.
The accessor check optimization code is dead code eliminated. A follow
up patch will fix this optimization correctly.
BUG=chromium:593634
Review-Url: https://codereview.chromium.org/1977983002
Cr-Commit-Position: refs/heads/master@{#36254}
We eagerly inserted Int32Mul for Math.imul during builtin lowering and
messed up with the types, which confused the representation selection.
This adds a proper NumberImul operator, and fixes the builtin reducer to
do the right thing according to the spec.
R=mstarzinger@chromium.org
BUG=v8:5006
LOG=n
Review-Url: https://codereview.chromium.org/1971163002
Cr-Commit-Position: refs/heads/master@{#36219}
The bailout points for named and keyed property loads when doing super
property calls are not being prepared by full-codegen, even though we
are using them in TurboFan for deopts and stack traces.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-4971
BUG=v8:4971
LOG=n
Review-Url: https://codereview.chromium.org/1960083002
Cr-Commit-Position: refs/heads/master@{#36109}
The flag in question used to fall-back to Crankshaft whenever an OSR
request couldn't be handled by TurboFan. By now OSR in TurboFan is
sufficiently stabilized that one single --use-osr flag should do it.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/1960043002
Cr-Commit-Position: refs/heads/master@{#36102}
Scope analysis is over-conservative when treating variable resolutions
as possibly-shadowed by a sloppy eval. In the attached bug, this comes
into play since catch scopes have different behavior with respect to
the "calls eval" in eager vs lazy compilation (in the latter, they
are never marked as "calls eval" because CatchContexts don't have
an associated ScopeInfo).
This patch changes the scope-type check to also eliminate a few other
cases where shadowing isn't possible, such as non-declaration block scopes.
BUG=chromium:608279
LOG=n
Review-Url: https://codereview.chromium.org/1950803002
Cr-Commit-Position: refs/heads/master@{#36046}
The inline allocation sequence in the optimizing compilers cannot deal
well with funky types like JSRegExp, which have some magic fields in
addition to the inobject properties. In Crankshaft we already use the
FastNewObjectStub for %_NewObject in general, so fix TurboFan to the same.
Hopefully one day we can kill %_NewObject completely.
R=jarin@chromium.org
BUG=chromium:609029
LOG=n
Review-Url: https://codereview.chromium.org/1943403004
Cr-Commit-Position: refs/heads/master@{#36006}
Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.
Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.
BUG=v8:4970
LOG=n
Review-Url: https://codereview.chromium.org/1931003003
Cr-Commit-Position: refs/heads/master@{#36001}
The ECMA 402 implementation previously pushed directly to real
Arrays, which risks having observably incorrect behavior in the
presence of monkey patching. This patch uses InternalArrays instead
to avoid that hazard.
R=jshin@chromium.org,yangguo@chromium.org
BUG=chromium:604299
LOG=N
Review-Url: https://codereview.chromium.org/1923803002
Cr-Commit-Position: refs/heads/master@{#35949}
Reason for revert:
[Sheriff] Looks like this breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/6442
Original issue's description:
> Remove more dead code after Object.observe removal
>
> This moves __{define,lookup}{Getter,Setter}__ to builtins.cc to free up the JavaScript implementation of DefineOwnProperty for deletion.
TBR=verwaest@chromium.org,jkummerow@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/1929293002
Cr-Commit-Position: refs/heads/master@{#35886}
These checks ensure that a TypeError is thrown, per spec, rather than
a runtime assert failure.
BUG=v8:4964
R=adamk
LOG=Y
Review-Url: https://codereview.chromium.org/1929123002
Cr-Commit-Position: refs/heads/master@{#35885}
This moves __{define,lookup}{Getter,Setter}__ to builtins.cc to free up the JavaScript implementation of DefineOwnProperty for deletion.
Review-Url: https://codereview.chromium.org/1904313004
Cr-Commit-Position: refs/heads/master@{#35876}
Between the miss and patching, we run user code. That may already patch the same code. IC refactoring broke this (again), so including a regression test this time around.
BUG=chromium:601392
LOG=n
Review URL: https://codereview.chromium.org/1925583002
Cr-Commit-Position: refs/heads/master@{#35811}
If the target is deprecated, the object will be updated on first store. If the source for that store equals the target, this will invalidate the cached representation of the source. Preventively upgrade the target.
BUG=chromium:604300
LOG=n
Review URL: https://codereview.chromium.org/1905933002
Cr-Commit-Position: refs/heads/master@{#35770}
Fixes a mistake made in r35618 for register OperandSize calculations.
BUG=605470
LOG=N
Review URL: https://codereview.chromium.org/1908033002
Cr-Commit-Position: refs/heads/master@{#35719}
This is a follow-up to 58429beb7b
"Fix KeyedStore stub selection for STRING_WRAPPER_ELEMENTS".
BUG=chromium:602184
LOG=n
Review URL: https://codereview.chromium.org/1912443004
Cr-Commit-Position: refs/heads/master@{#35715}
The feature was deprecated in M49 and flagged off in M50.
This patch removes it entirely from the codebase.
Review URL: https://codereview.chromium.org/1909433003
Cr-Commit-Position: refs/heads/master@{#35714}
Non-vectorized KeyedLoadICs used to remember whether they had seen Names
as keys; Crankshaft uses this information to avoid emitting elements
accesses which would always deopt. This CL restores that functionality
for vector ICs.
BUG=chromium:594183
LOG=y
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1912593002
Cr-Commit-Position: refs/heads/master@{#35706}
Our previous over-conservative answer caused us to emit hole checks in
full-codegen when eagerly parsing but not when lazily parsing.
With this patch, we use the positions of the BinaryOperations making up
the parameter list (which are the positions of the commas) to determine
the appropriate "end position" for each parameter's initializer. This means
that we get accurate-enough positions for the initializers in the eager
parsing step to get the same answers for hole-check-elimination that we
will later during ParseLazy.
In the included test case, for example:
(function() { ((s = 17, y = s) => s)(); } )();
^2 ^1
The old code would generate a hole check when trying to load
|s| for assignment to |y| (because it treated the closing parentheses
pointed to by "^1" as the "initialization position" of |s|).
The new code uses the comma pointed to by "^2" as the initialization
position of |s|. Since that occurs textually before the load of |s|,
full-codegen knows it can avoid the hole check.
BUG=v8:4908
LOG=n
Review URL: https://codereview.chromium.org/1900343002
Cr-Commit-Position: refs/heads/master@{#35678}
Also factor out test cases from test-run-machops.cc into test-run-load-store.cc
BUG=chromium:599717
LOG=Y
Review URL: https://codereview.chromium.org/1858323003
Cr-Commit-Position: refs/heads/master@{#35651}
Add support to optimize certain comparisons of typeof with known
strings to utilize the existing ObjectIs<Type> predicates. Also
add a new ObjectIsCallable, which is used to optimize the common
typeof x === "function" pattern.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1898653003
Cr-Commit-Position: refs/heads/master@{#35562}
Reason for revert:
Did not fail on another roll including this CL ..
Original issue's description:
> Revert of [compiler] Make feedback vector cope with flag changes. (patchset #1 id:1 of https://codereview.chromium.org/1869693003/ )
>
> Reason for revert:
> Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001
>
> Original issue's description:
> > [compiler] Make feedback vector cope with flag changes.
> >
> > This fixes corner cases where the layout of feedback vectors baked into
> > the snapshot is different from the expected layout, depending on some
> > runtime flags. We make sure the feedback vector is regenereated for
> > functions that are not compiled. Flag changes of this kind are only
> > allowed when code is not serialized.
> >
> > An alternative solution would be to not serialize the feedback vector
> > for such cases in the first place. That solution however would have a
> > higher overhead, as it would required the serializer to be able to
> > recognize feedback vectors while generating a snapshot.
> >
> > R=mvstanton@chromium.org
> > TEST=mjsunit/regress/regress-crbug-600995
> > BUG=chromium:600995
> > LOG=n
> >
> > Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> > Cr-Commit-Position: refs/heads/master@{#35339}
>
> TBR=mvstanton@chromium.org,mstarzinger@chromium.org
>
> BUG=chromium:600995
> LOG=N
> NOTRY=true
>
> Committed: https://crrev.com/78049e9c4837f053575d6c71e53ae12fec99f1aa
> Cr-Commit-Position: refs/heads/master@{#35392}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:600995
Review URL: https://codereview.chromium.org/1876973002
Cr-Commit-Position: refs/heads/master@{#35398}
Reason for revert:
Blocks current roll: https://codereview.chromium.org/1876713002/ according to bisect: https://codereview.chromium.org/1872353002/#ps80001
Original issue's description:
> [compiler] Make feedback vector cope with flag changes.
>
> This fixes corner cases where the layout of feedback vectors baked into
> the snapshot is different from the expected layout, depending on some
> runtime flags. We make sure the feedback vector is regenereated for
> functions that are not compiled. Flag changes of this kind are only
> allowed when code is not serialized.
>
> An alternative solution would be to not serialize the feedback vector
> for such cases in the first place. That solution however would have a
> higher overhead, as it would required the serializer to be able to
> recognize feedback vectors while generating a snapshot.
>
> R=mvstanton@chromium.org
> TEST=mjsunit/regress/regress-crbug-600995
> BUG=chromium:600995
> LOG=n
>
> Committed: https://crrev.com/460bff5fb6af2bd79e610f89afdf6da9dba3cf0c
> Cr-Commit-Position: refs/heads/master@{#35339}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
BUG=chromium:600995
LOG=N
NOTRY=true
Review URL: https://codereview.chromium.org/1876103002
Cr-Commit-Position: refs/heads/master@{#35392}
Function bindings are the only variables in LEGACY_CONST mode.
(https://codereview.chromium.org/1819123002/). Since these variables
can also be accessed in strict mode functions we should support
handling such variables. Assigning to a legacy constant throws
a TypeError in strict mode. Also fixes hydrogen.cc to throw a
TypeError for legacy constants.
BUG=v8:4280,chromium:599068
LOG=N
TBR=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1845223006
Cr-Commit-Position: refs/heads/master@{#35383}
This fixes corner cases where the layout of feedback vectors baked into
the snapshot is different from the expected layout, depending on some
runtime flags. We make sure the feedback vector is regenereated for
functions that are not compiled. Flag changes of this kind are only
allowed when code is not serialized.
An alternative solution would be to not serialize the feedback vector
for such cases in the first place. That solution however would have a
higher overhead, as it would required the serializer to be able to
recognize feedback vectors while generating a snapshot.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-600995
BUG=chromium:600995
LOG=n
Review URL: https://codereview.chromium.org/1869693003
Cr-Commit-Position: refs/heads/master@{#35339}
Pushing undefined onto a FAST_DOUBLE_ARRAY does not enforce the right representation checks.
BUG=chromuim:599089
LOG=n
Review URL: https://codereview.chromium.org/1868973002
Cr-Commit-Position: refs/heads/master@{#35332}
We have to preserve control flow so that the liveness analysis is less
confused. This CL fixes loops to preserve teh original control flow.
BUG=chromium:599710
LOG=n
Review URL: https://codereview.chromium.org/1863123002
Cr-Commit-Position: refs/heads/master@{#35318}
Previously, CreateDataProperty would fail a DCHECK when used to create
an integer indexed property on a TypedArray. This patch makes it throw
a TypeError instead. The issue came up when Array.prototype.concat
was repaired to use CreateDataProperty rather than SetElement; concat
can be tricked into making a new TypedArray if it is given an Array
whose prototype is a TypedArray. This patch prevents the issue.
R=adamk
LOG=Y
BUG=chromium:596394
Review URL: https://codereview.chromium.org/1821723004
Cr-Commit-Position: refs/heads/master@{#35271}
In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.
In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).
BUG=chromium:599412
LOG=n
Review URL: https://codereview.chromium.org/1857133003
Cr-Commit-Position: refs/heads/master@{#35259}
This fixes a corner case where the generator function of a suspended
generator has been marked for optimization. We assume the optimization
approach will cause a bailout because generators are not optimized. But
resuming is more resilient by always activating the unoptimized code.
R=neis@chromium.org,bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-513471
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1856683002
Cr-Commit-Position: refs/heads/master@{#35234}
This CL ensures that we build environments/frame states so that tail caller frame will never become topmost.
BUG=chromium:598998, v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1849503002
Cr-Commit-Position: refs/heads/master@{#35188}
The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).
R=verwaest@chromium.org
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1845243005
Cr-Commit-Position: refs/heads/master@{#35187}
Fix and re-enable the flexible representation for Math.floor (which is used to
implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
return double results instead of int32, and therefore allows values outside
the int32 range, especially -0 is now a valid result, which doesn't deopt.
Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
extension.
This addresses all the known deoptimization loops related to Math.round
in the Kraken benchmark suite, and seems to also address most of the
deoptimization loops related to Math.floor in the Oort Online benchmark.
Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
optimization that caused the initial revert of the feature (for arm64 only
back then).
BUG=chromium:476477,v8:2890,v8:4059
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1841513003
Cr-Commit-Position: refs/heads/master@{#35094}
It's been on since M49. Also moved tests from harmony -> es6,
one of which was merged with another test of the same name.
While moving stuff over to regexp.js, I also noticed that there
were unused calls to %FunctionSetName and %SetNativeFlag (those
calls are already handled by InstallGetter()).
Review URL: https://codereview.chromium.org/1838563003
Cr-Commit-Position: refs/heads/master@{#35076}
A bug in error printing meant that we failed to do proper type checks
before calling into C++ code, which could lead to RUNTIME_ASSERT
failures if methods are called on alternative receivers. This patch
adds the right type checks.
BUG=chromium:596718
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1831053003
Cr-Commit-Position: refs/heads/master@{#35069}
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.
In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.
Also gone are any tests which relied on legacy const declarations.
Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.
Review URL: https://codereview.chromium.org/1819123002
Cr-Commit-Position: refs/heads/master@{#35002}
Both of them shipped in Chrome 49 without incident.
Also move relevant tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1815773002
Cr-Commit-Position: refs/heads/master@{#34964}
This is necessary to ensure that "Called non callable" exception will get a proper message and stack trace even for calls at tail position.
BUG=chromium:595615, v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1818003002
Cr-Commit-Position: refs/heads/master@{#34962}
Previously only JSFunctions seemed to be valid for toJSON, which doesn't
match the ES6 specification that allows any object with [[Call]]
internal method (i.e. any Callable in V8 terminology), including bound
functions and proxies.
BUG=chromium:595738, chromium:535408
R=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1824533002
Cr-Commit-Position: refs/heads/master@{#34913}
This patch fixes two bugs in Array.prototype.concat in conjunction with
subclassing Arrays:
- Create a new property rather than calling Set when adding elements to
the output array. This means setters are not called.
- If there is an exception thrown from DefineProperty, propagate it
outwards properly, rather than swallowing it. This can occur, e.g., with
a Proxy as the new output array.
R=adamk
LOG=Y
BUG=chromium:595319
Review URL: https://codereview.chromium.org/1814933002
Cr-Commit-Position: refs/heads/master@{#34876}
Repair this to match what the runtime correctly does, by first checking if the
function is a constructor before we access the prototype.
R=verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1810953002
Cr-Commit-Position: refs/heads/master@{#34863}
Function declarations were previously permitted by V8 in many locations
which no ECMAScript specification allowed; the ECMAScript 2015 spec
enumerates a few locations (in blocks, as well as after labels and in
conditionals when in sloppy mode). This patch ships the flag to restrict
the usage of function declarations to those contexts.
R=adamk
LOG=Y
BUG=v8:4824
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1799233003
Cr-Commit-Position: refs/heads/master@{#34828}
The monomorphic case already carefully ensures that we don't try to use
a regular elements load stub on string wrapper elements. The polymorphic
path must perform an equivalent check.
BUG=chromium:594955
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1806543002
Cr-Commit-Position: refs/heads/master@{#34807}
This part of Scope has existed since V8's initial check in, but from what
I can tell it's not required to implement "with". The only tests that
depend upon it are tests of the debugger and the Scope mirrors, but the
resulting test behavior after removing the bit still seems perfectly
reasonable to me. In fact, with the included fix for scope name collection,
the scope mirror is actually improved with this change.
As a bi-product, this fixes the attached bug, about the contains_with
bit having inconsistent values in some arrow function compilation
scenarios.
BUG=chromium:592353
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1804783002
Cr-Commit-Position: refs/heads/master@{#34802}
Array.prototype.concat did not work correct with complex elements on the
receiver or the prototype chain.
BUG=chromium:594574
LOG=y
Review URL: https://codereview.chromium.org/1804963002
Cr-Commit-Position: refs/heads/master@{#34798}
These flags have been on by default since version 4.9, which has been
in stable Chrome for over a week now, demonstrating that they're
here to stay.
Also moved the tests out of harmony/ and into es6/.
Review URL: https://codereview.chromium.org/1776683003
Cr-Commit-Position: refs/heads/master@{#34692}
When an Array subclass is used as the receiver for concat, or with
certain usages of @@species, the output that's constructed is of
a different type with new slow path logic. This slow path still
made references to elements, so it's important that bounds checking
for a too-long result still be done. This patch repairs that bounds
checking.
R=cbruni
LOG=Y
BUG=chromium:592340
Review URL: https://codereview.chromium.org/1782443002
Cr-Commit-Position: refs/heads/master@{#34636}
Reading the registers' values back from the FrameDescription
should use the same offset computation as storing them into it.
The offsets must also match what the deoptimizer expects, which
is rx at offset rx.code() * kDoubleSize, even if some registers
are not saved (leaving gaps).
BUG=v8:4800
LOG=n
R=danno@chromium.org
Review URL: https://codereview.chromium.org/1769833006
Cr-Commit-Position: refs/heads/master@{#34633}
The CharacterRange constructor checks the input for validity. However,
CharacterRange::Singleton also uses the constructor and may have
kEndMarker as input, causing the check to fail.
The solution is to move the check to CharacterRange::Range and
consistently use it across the code base.
R=jkummerow@chromium.org
BUG=chromium:593282
LOG=N
Review URL: https://codereview.chromium.org/1776013003
Cr-Commit-Position: refs/heads/master@{#34626}
After fixing the memory barrier for maps (https://codereview.chromium.org/1714513003), we are using a temp register for the map case. The temp register should not be aliased with the stored value (otherwise we perform the mem barrier check with a wrong value). This CL makes sure it is not aliased.
BUG=chromium:590074
LOG=n
Review URL: https://codereview.chromium.org/1775083002
Cr-Commit-Position: refs/heads/master@{#34607}
We cannot optimize away ToNumber conversions based on the Type that we
see in Crankshaft, as this might be the (unchecked or even pretruncated)
lower bound. We can only use the HType, which is based on the definition.
R=jkummerow@chromium.org
BUG=chromium:590989
LOG=n
Review URL: https://codereview.chromium.org/1757013002
Cr-Commit-Position: refs/heads/master@{#34445}
We used to emit debug break location on block entry. This cannot be
ported to the interpreted as we do not emit bytecode for block entry.
This made no sense to begin with though, but accidentally added
break locations for var declarations.
With this change, the debugger no longer breaks at var declarations
without initialization. This is in accordance with the fact that the
interpreter does not emit bytecode for uninitialized var declarations.
Also fix the bytecode to match full-codegen's behavior wrt return
positions:
- there is a break location before the return statement, with the source
position of the return statement.
- right before the actual return, there is another break location. The
source position points to the end of the function.
R=rmcilroy@chromium.org, vogelheim@chromium.orgTBR=rossberg@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1744123003
Cr-Commit-Position: refs/heads/master@{#34388}
The CompareICStub produces an untagged raw word value, which has to be
translated to true or false manually in the TurboFan code. But for lazy
bailout after the CompareIC, we immediately go back to fullcodegen or
Ignition with the raw value, to a location where both fullcodegen and
Ignition expect a boolean value, which might crash or in the worst case
(depending on the exact computation inside the CompareIC) could lead to
arbitrary memory access.
Short-term fix is to use the proper runtime functions (unified with the
interpreter now) for comparisons. Next task is to provide optimized
versions of these based on the CodeStubAssembler, which can then be used
via code stubs in TurboFan or directly in handlers in the interpreter.
R=mstarzinger@chromium.org
BUG=v8:4788
LOG=n
Review URL: https://codereview.chromium.org/1738153002
Cr-Commit-Position: refs/heads/master@{#34335}
The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).
This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.
R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y
Review URL: https://codereview.chromium.org/1740123002
Cr-Commit-Position: refs/heads/master@{#34322}
This fixes a corner case that triggered an assert in full-codegens
operand stack depth tracking. We stop pushing operands if we overflow
the C-stack while iterating the AST. This makes the tracking go out of
sync before we fully returned from the tree traversal, at which point
the thrown RangeError will abort compilation.
R=ishell@chromium.org
TEST=mjsunit/regress/regress-crbug-589472
BUG=chromium:589472
LOG=n
Review URL: https://codereview.chromium.org/1732903002
Cr-Commit-Position: refs/heads/master@{#34255}
The Crankshaft fast case for String.fromCharCode() unconditionally
deoptimizes on all non-int32 inputs, even tho it would be perfectly
valid to just truncate the index to an int32.
R=ishell@chromium.org
BUG=chromium:587068
LOG=n
Review URL: https://codereview.chromium.org/1727873003
Cr-Commit-Position: refs/heads/master@{#34243}
It turns out that some old polyfill library uses
RegExp.prototype.flags as a way of feature testing. It's not clear
how widespread this is. For now, as a minimal workaround, we can
return undefined from getters like RegExp.prototype.global when
the receiver is RegExp.prototype. This patch implements that strategy
but omits a UseCounter to make backports easier.
R=adamk
CC=yangguo@chromium.org
BUG=chromium:581577
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1640803003
Cr-Commit-Position: refs/heads/master@{#34201}
This was changed to match Annex B.2.5.1 of ES2015 and Firefox in
https://chromium.googlesource.com/v8/v8/+/469d9bfa, but website
breakage was seen in M49 Beta. JSC still returns undefined here.
BUG=chromium:585775
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1714903004
Cr-Commit-Position: refs/heads/master@{#34172}
Drive-by-fix: Remove the (now) unused %_SetValueOf and %_JSValueGetValue
intrinsics from the various compilers and the runtime.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1698343002
Cr-Commit-Position: refs/heads/master@{#34037}
for the special case where the same register is used as both left and
right input.
Review URL: https://codereview.chromium.org/1695283002
Cr-Commit-Position: refs/heads/master@{#33996}
This removes support for the %Arguments and %ArgumentsLength runtime
entries and their intrinsic counterparts. If you need variable arguments
in any builtin, either use (strict) arguments object or rest parameters,
which are both compositional across inlining (in TurboFan), and not that
much slower compared to the %_Arguments hackery.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1688163004
Cr-Commit-Position: refs/heads/master@{#33943}
This fact is depended upon by, at least, Parser::ParseLazy, and quite
likely by other code. There was already code in %FunctionSetName
enforcing this invariant. This patch adds similar code to
Factory::NewSharedFunctionInfo().
BUG=v8:4659
LOG=n
Review URL: https://codereview.chromium.org/1686193003
Cr-Commit-Position: refs/heads/master@{#33914}
ES2016 TypedArray subclassing semantics break the Node.js Buffer module,
also used on the web. I wrote a pull request against the web and Node
versions to fix the issue, but the pull request has not yet been granted,
and this is blocking shipping the change. For now, this patch extends the
web compatibility workaround to the --harmony-species flag, so that
Symbol.species and associated subclassing semantics can ship independently.
R=cbruni
BUG=v8:4665
LOG=Y
Review URL: https://codereview.chromium.org/1678123002
Cr-Commit-Position: refs/heads/master@{#33826}
Trying to sort a string should throw a TypeError, proper handling
of elements just needs to get out of the way.
BUG=chromium:584188
LOG=n
R=cbruni@chromium.org
Review URL: https://codereview.chromium.org/1670153002
Cr-Commit-Position: refs/heads/master@{#33777}
This removes --harmony-completion, --harmony-concat-spreadable, and
--harmony-tolength and moves the appropriate tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1667453002
Cr-Commit-Position: refs/heads/master@{#33712}
This was inconsistent in the spec in case of has vs get, set. Removing
receiver==holder simplifies the lookup; so tentatively removing this
additional check which was broken until yesterday anyway. See
https://github.com/tc39/ecma262/issues/347 for more information.
Review URL: https://codereview.chromium.org/1660903002
Cr-Commit-Position: refs/heads/master@{#33701}
This includes 2 fixes:
1) We didn't properly advance the holder when checking whether
Receiver==Holder, so we'd inadvertently block loading the property if
the first property we find is on the typed array.
2) Reflect.get may cause any object on the prototype chain of the holder
to be the receiver; so we need to recheck for this special state for
each object we perform lookup on.
Review URL: https://codereview.chromium.org/1651913005
Cr-Commit-Position: refs/heads/master@{#33689}
This patch adds a UseCounter for each of the following:
- Allowing duplicate sloppy-mode block-scoped function declarations
in the exact same scope
- for-in loops with an initializer
The patch also refactors some of the declaration code to clean it up and
enable the first counter, and adds additional unit tests to nail down
the semantics of edge cases of sloppy-mode block-scoped function declarations.
BUG=v8:4693,chromium:579395
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1633743003
Cr-Commit-Position: refs/heads/master@{#33650}
In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.
R=rossberg@chromium.org
BUG=chromium:582051
LOG=N
Review URL: https://codereview.chromium.org/1648263002
Cr-Commit-Position: refs/heads/master@{#33627}
Previously, String.prototype.normalize constructed its ICU input
string as a null-terminated string. This creates a bug for strings
which contain a null byte, which is allowed in ECMAScript. This
patch constructs the ICU string based on its length so that the
entire string is normalized.
R=jshin@chromium.org
BUG=v8:4654
LOG=Y
Review URL: https://codereview.chromium.org/1645223003
Cr-Commit-Position: refs/heads/master@{#33614}
The for-in slow mode implementation in Crankshaft unconditionally
deoptimizes when %ForInFilter returns undefined instead of just
skipping the item. Even worse, there's nothing we can learn from
that deopt, so we will eventually optimize again and hit exactly
the same problem again once we get back to optimized code.
R=mvstanton@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1647093002
Cr-Commit-Position: refs/heads/master@{#33609}
So far the for-in slow path in Crankshaft unconditionally called
%ForInFilter for every iteration of the for-in loop, without paying
attention to the possible enum cache equipped receiver map. So even
though we iterate the enum cache FixedArray associated with the map
we don't check the map, but always go to %ForInFilter. This would be
perfectly fine if the enum cache FixedArray would be immutable, but
due to some funny GC/runtime interaction kicking in, the enum cache
can be right trimmed while we are iterating it, and the only way to
detect this is to ensure that we check the map when accessing the
enum cache.
BUG=v8:3650,v8:4715
LOG=n
Review URL: https://codereview.chromium.org/1650493002
Cr-Commit-Position: refs/heads/master@{#33599}
ParseArrowFunctionLiteral was erroneously checking AllowsLazyCompilation
rather than AllowsLazyParsing when deciding whether to parse lazily.
This meant that lexically-scoped variables that had no other referents
wouldn't get closed over properly.
BUG=chromium:580934, v8:4255
LOG=y
Review URL: https://codereview.chromium.org/1630823006
Cr-Commit-Position: refs/heads/master@{#33530}
The web appears to depend on being able to redeclare functions-in-blocks
in sloppy mode (examples seen so far tend to redeclare identical functions,
most likely accidentally).
This patch opens a minimal hole: two same-named function declarations
in the same scope are allowed, only in sloppy mode.
BUG=v8:4693, chromium:579395
LOG=y
Review URL: https://codereview.chromium.org/1622723003
Cr-Commit-Position: refs/heads/master@{#33478}
In case the receiver map has an enum cache, %ForInPrepare returns the
length of the actual enum cache, which might include properties that
are further down the transition tree tho.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1619353002
Cr-Commit-Position: refs/heads/master@{#33469}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33461}
Reason for revert:
let me quickly revert the revert, wut?
Goal: my CL should not be in the tree!
Original issue's description:
> Reland of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #1 id:1 of https://codereview.chromium.org/1619803003/ )
>
> Reason for revert:
> the deopt issues have been taken care of by benedikt
>
> Original issue's description:
> > Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
> >
> > Reason for revert:
> > tanks for-in significantly
> >
> > Original issue's description:
> > > [runtime] Do not use the enum-cache for keys retrieval.
> > >
> > > Currently we fail to properly handle shadowed properties. If the
> > > receiver defines a non-enumerable property that reappears on the
> > > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > > By extending the KeyAccumulator to track non-enumerable properties
> > > we can now properly filter them out when seeing them further up in
> > > the prototype-chain.
> > >
> > > BUG=v8:705
> > > LOG=y
> > >
> > > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > > Cr-Commit-Position: refs/heads/master@{#33405}
> >
> > TBR=jkummerow@chromium.org,bmeurer@chromium.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=v8:705
> > LOG=n
> >
> > Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> > Cr-Commit-Position: refs/heads/master@{#33443}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:705
>
> Committed: https://crrev.com/5569e270eda517b5ea74e3a7676b3230cbe2f7a9
> Cr-Commit-Position: refs/heads/master@{#33458}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1614313003
Cr-Commit-Position: refs/heads/master@{#33459}
Reason for revert:
the deopt issues have been taken care of by benedikt
Original issue's description:
> Revert of [runtime] Do not use the enum-cache for non-prototype objects. (patchset #10 id:180001 of https://codereview.chromium.org/1608523002/ )
>
> Reason for revert:
> tanks for-in significantly
>
> Original issue's description:
> > [runtime] Do not use the enum-cache for keys retrieval.
> >
> > Currently we fail to properly handle shadowed properties. If the
> > receiver defines a non-enumerable property that reappears on the
> > prototype as enumerable it incorrectly shows up in [[Enumerate]].
> > By extending the KeyAccumulator to track non-enumerable properties
> > we can now properly filter them out when seeing them further up in
> > the prototype-chain.
> >
> > BUG=v8:705
> > LOG=y
> >
> > Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> > Cr-Commit-Position: refs/heads/master@{#33405}
>
> TBR=jkummerow@chromium.org,bmeurer@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:705
> LOG=n
>
> Committed: https://crrev.com/6e0573c6fff1c3041bab106d1197ab1b64aa9a6a
> Cr-Commit-Position: refs/heads/master@{#33443}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:705
Review URL: https://codereview.chromium.org/1612413003
Cr-Commit-Position: refs/heads/master@{#33458}
The internal index used to implement for-in can never leave the
valid smi range, so there's no need to actually check for overflow
in Crankshaft. In fact the overflow only triggered a false alert
in the deopt fuzzer.
R=jarin@chromium.org
BUG=v8:3650
LOG=n
Review URL: https://codereview.chromium.org/1621623002
Cr-Commit-Position: refs/heads/master@{#33456}
Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077
Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267
Review URL: https://codereview.chromium.org/1611313003
Cr-Commit-Position: refs/heads/master@{#33444}
Reason for revert:
tanks for-in significantly
Original issue's description:
> [runtime] Do not use the enum-cache for keys retrieval.
>
> Currently we fail to properly handle shadowed properties. If the
> receiver defines a non-enumerable property that reappears on the
> prototype as enumerable it incorrectly shows up in [[Enumerate]].
> By extending the KeyAccumulator to track non-enumerable properties
> we can now properly filter them out when seeing them further up in
> the prototype-chain.
>
> BUG=v8:705
> LOG=y
>
> Committed: https://crrev.com/ed24dfe80d1da0827b8571839ee52c03ad09c9c7
> Cr-Commit-Position: refs/heads/master@{#33405}
TBR=jkummerow@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:705
LOG=n
Review URL: https://codereview.chromium.org/1619803003
Cr-Commit-Position: refs/heads/master@{#33443}
When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
BUG=v8:4267
LOG=Y
Review URL: https://codereview.chromium.org/1587073003
Cr-Commit-Position: refs/heads/master@{#33438}
Currently we fail to properly handle shadowed properties. If the
receiver defines a non-enumerable property that reappears on the
prototype as enumerable it incorrectly shows up in [[Enumerate]].
By extending the KeyAccumulator to track non-enumerable properties
we can now properly filter them out when seeing them further up in
the prototype-chain.
BUG=v8:705
LOG=y
Review URL: https://codereview.chromium.org/1608523002
Cr-Commit-Position: refs/heads/master@{#33405}
Proxy.
If a constructable Proxy changes the target's prototype during the
prototype lookup the target's initial map stays uninitialized half-way
during object construction.
LOG=n
BUG=chromium:578039
Review URL: https://codereview.chromium.org/1586203003
Cr-Commit-Position: refs/heads/master@{#33359}
When derived constructors return a non-object (or not undefined) we
currently throw an exception directly in the callee context. This was
achieved by desugaring the return statement for derived classes. To
be spec compliamnt a separate ConstructStubForDerived is introduced.
Instead of trowing directly, the desugared return statement inside
a derived constructor only returns an integer to indicate an incompatible
result.
BUG=v8:4509
LOG=n
Review URL: https://codereview.chromium.org/1593553002
Cr-Commit-Position: refs/heads/master@{#33336}
Previous changes with subclassable builtins and @@species were a bit
aggressive in making TypedArray.prototype.subarray act like the
ES2016 specification in terms of returning an instance of the
subclass as a result. It turns out that Node.js, and extracted
libraries for the web, subclass TypedArrays but don't expect the
subclass constructor to be called by subarray. @@species will provide
an escape hatch, but it has not shipped yet, and will take some time
for uptake by libraries.
For now, this patch makes TypedArray.prototype.subarray fall back to
constructing an instance of the parent TypedArray class, such as
Uint8Array.
R=adamk
LOG=Y
BUG=v8:4665
Review URL: https://codereview.chromium.org/1583773005
Cr-Commit-Position: refs/heads/master@{#33312}
This avoids generating different scopes on the two compilation passes, which
results in various delirious side-effects.
There's some cleanup to be done in lazy arrow function parsing, but I'd
rather do that in a separate patch, with this one targeted at fixing the
particular crash.
BUG=chromium:572589
LOG=n
Review URL: https://codereview.chromium.org/1575333004
Cr-Commit-Position: refs/heads/master@{#33311}
As luck would have it, there doesn't seem to be a way to trigger
observable misbehavior currently (only with special flags).
BUG=chromium:380671
LOG=n
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1588013002
Cr-Commit-Position: refs/heads/master@{#33305}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
Cr-Commit-Position: refs/heads/master@{#33228}
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33231}
Reason for revert:
[Sheriff] Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/5711
Original issue's description:
> [builtins] Refactor the remaining Date builtins.
>
> This migrates the remaining Date builtins to C++ and removes obsolete
> intrinsics and JavaScript wrappers. This reduces the overhead imposed
> by the Date builtins, and will allow us to optimize them later in the
> TurboFan compiler, while the interpreter doesn't need to worry about
> them.
>
> R=yangguo@chromium.org
> BUG=chromium:576574
> LOG=n
>
> Committed: https://crrev.com/1e51af1a5c80b1650de47dd4bc8f846fa2d85281
> Cr-Commit-Position: refs/heads/master@{#33228}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:576574
Review URL: https://codereview.chromium.org/1574223002
Cr-Commit-Position: refs/heads/master@{#33230}
This migrates the remaining Date builtins to C++ and removes obsolete
intrinsics and JavaScript wrappers. This reduces the overhead imposed
by the Date builtins, and will allow us to optimize them later in the
TurboFan compiler, while the interpreter doesn't need to worry about
them.
R=yangguo@chromium.org
BUG=chromium:576574
LOG=n
Review URL: https://codereview.chromium.org/1579613002
Cr-Commit-Position: refs/heads/master@{#33228}
This patch improves ArrayBuffer and TypedArray subclassing by adding
support for @@species and constructing outputs to certain methods
by creating an instance of the constructor determined by the
SpeciesConstructor algorithm, rather than fixed to a superclass or
naively the constructor. The new behavior is enabled by the
--harmony-species flag. Care is taken to not significantly change the
observable behavior when the flag is off. Previously, TypedArrays
already supported subclassing by reading the constructor of the
receiver, but ArrayBuffers did not, and this old behavior is
preserved and tested for, to avoid a multi-stage upgrade path and keep
things simple for users.
R=adamk
BUG=v8:4093
LOG=Y
Review URL: https://codereview.chromium.org/1574903004
Cr-Commit-Position: refs/heads/master@{#33223}
This patch moves the semantics of 'const' in sloppy mode to match those
in strict mode, that is, const makes lexical (let-like) bindings, must
have an initializer, and does not create properties of the global object.
R=adamk
LOG=Y
BUG=v8:3305
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1571873004
Cr-Commit-Position: refs/heads/master@{#33218}
As V8 becomes more and more spec-compliant, Promise polyfill libraries
like core.js expect fully correct. However, our Promises do not yet
support Symbol.species. Therefore, a case like
```
var test = new Promise(function(){});
test.constructor = function(){};
Promise.resolve(test)
```
would lead to an unhandled Promise rejection, whereas it should not
because test.constructor[Symbol.species] is undefined, so test.then
should end up constructing %Promise% as a fallback, rather than
calling test.constructor as if it were a constructor, which leads
this error checking code to throw.
For now, this patch removes the error checking code (which was not
present until recently). In an interactive test using core.js, the
error message on the console goes away with this patch. When @@species
support is in place, this patch can be reverted. A regression test
is added which checks for the same thing.
Partially reverted patch was originally out for review at
https://codereview.chromium.org/1531073004
BUG=v8:4633
LOG=Y
R=adamk,caitp88@gmail.com
Review URL: https://codereview.chromium.org/1578893002
Cr-Commit-Position: refs/heads/master@{#33217}
Reason for revert:
Crash fixed by https://codereview.chromium.org/1564923007
Original issue's description:
> Revert of Ship ES2015 sloppy-mode function hoisting, let, class (patchset #7 id:120001 of https://codereview.chromium.org/1551443002/ )
>
> Reason for revert:
> Causes frequent crashes in Canary: chromium:537816
>
> Original issue's description:
> > Ship ES2015 sloppy-mode function hoisting, let, class
> >
> > This patch doesn't ship all features of ES2015 variable/scoping
> > changes, notably omitting the removal of legacy const. I think
> > function hoisting, let and class in sloppy mode can stand to
> > themselves as a package, and the legacy const change is much
> > riskier and more likely to be reverted, so my intention is to
> > pursue those as a separate, follow-on patch.
> >
> > R=adamk@chromium.org
> > BUG=v8:4285,v8:3305
> > LOG=Y
> > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> >
> > Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> > Cr-Commit-Position: refs/heads/master@{#33133}
>
> TBR=adamk@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=v8:4285,v8:3305,chromium:537816
> LOG=Y
>
> Committed: https://crrev.com/adac5956c6216056a211cfaa460a00ac1500d8f8
> Cr-Commit-Position: refs/heads/master@{#33162}
TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4285,v8:3305,chromium:537816
Review URL: https://codereview.chromium.org/1571793002
Cr-Commit-Position: refs/heads/master@{#33189}
Reason for revert:
Causes frequent crashes in Canary: chromium:537816
Original issue's description:
> Ship ES2015 sloppy-mode function hoisting, let, class
>
> This patch doesn't ship all features of ES2015 variable/scoping
> changes, notably omitting the removal of legacy const. I think
> function hoisting, let and class in sloppy mode can stand to
> themselves as a package, and the legacy const change is much
> riskier and more likely to be reverted, so my intention is to
> pursue those as a separate, follow-on patch.
>
> R=adamk@chromium.org
> BUG=v8:4285,v8:3305
> LOG=Y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/fcff8588a5a01587643d6c2507c7b882c78a2957
> Cr-Commit-Position: refs/heads/master@{#33133}
TBR=adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4285,v8:3305,chromium:537816
LOG=Y
Review URL: https://codereview.chromium.org/1565263002
Cr-Commit-Position: refs/heads/master@{#33162}
Some tests passed a string as second argument to assertThrows, expecting it to
be matched against the exception. However, assertThrows simply ignored these.
(Some other tests actually seem to use that argument as a comment ...)
This CL
- changes assertThrows to fail if the second argument is not a function,
- adds assertThrowsEquals which compares the exception to a given value using
assertEquals
- fixes some bogus tests that got exposed by this.
R=jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1544793002
Cr-Commit-Position: refs/heads/master@{#33159}
This patch doesn't ship all features of ES2015 variable/scoping
changes, notably omitting the removal of legacy const. I think
function hoisting, let and class in sloppy mode can stand to
themselves as a package, and the legacy const change is much
riskier and more likely to be reverted, so my intention is to
pursue those as a separate, follow-on patch.
R=adamk@chromium.org
BUG=v8:4285,v8:3305
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1551443002
Cr-Commit-Position: refs/heads/master@{#33133}
For a prototype chain foo -> global_proxy -> global_object, we used to
register a dependency from foo -> global_object. This is incorrect when
the global_proxy/global_object pairing is modified, e.g. when navigating
in iframes. With this patch, we properly register foo -> global_proxy and
global_proxy -> global_object dependencies.
Additionally, when a prototype's prototype changes from null to something
else, this new usage relation must be registered if there are other users
further down on the prototype chain that might expect a complete chain of
registrations to exist (which was the case before, and must be preserved).
BUG=chromium:571517
LOG=n
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1559323002
Cr-Commit-Position: refs/heads/master@{#33119}
In the Date constructor or Date.parse, other browsers will accept time
zones like GMT-8, but before this patch, Chrome would interpret 8 as
8 minutes. This patch interprets GMT-+ a one or two digit number as hours,
not minutes.
R=adamk,jshin@chromium.org
LOG=Y
BUG=chromium:422858
Review URL: https://codereview.chromium.org/1557053002
Cr-Commit-Position: refs/heads/master@{#33100}
1. Location names with more than one underscores (e.g. Ho_Chi_Minh)
didn't work because of the way capturing works with repeated patterns
in RE. It's now supported by changing the RE to capture the whole string
and splitting on '_' in the next step.
2. Adds support for location names with a hyphen
3. Adds support for timezone ids with three parts (e.g.
American/Argentina/Buenos_Aires)
4. Adds special handling of 'au', 'es' and 'of' in zone ids. They need to be kept in lowercase. (see the full list at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones )
5. Adds regression tests for all the above and make the existing tests
more robust against future ICU changes. ICU canonicalizes zone names to
deprecated names, but it may change. (
http://bugs.icu-project.org/trac/ticket/12044 )
BUG=364374
LOG=Y
Review URL: https://codereview.chromium.org/1529363005
Cr-Commit-Position: refs/heads/master@{#33097}
In addition to ThrowTypeError not being a constructor, it was invalidly set up by simply swapping the map. Swapping the map is insufficient since NewFunction* actually set up the function depending on the used map.
BUG=chromium:573858
LOG=n
Review URL: https://codereview.chromium.org/1552223002
Cr-Commit-Position: refs/heads/master@{#33082}
The Object.freeze, Object.isExtensible, Object.isFrozen,
Object.isSealed, Object.preventExtensions and Object.seal builtins were
already implemented in C++, but they still had some funny JavaScript
wrappers that just called into the C++ implementation on every
(interesting) execution path.
Review URL: https://codereview.chromium.org/1553043002
Cr-Commit-Position: refs/heads/master@{#33074}
Unify the constructors and isView methods for ArrayBuffer and
SharedArrayBuffer, moving them to C++ because there's no point
in having the JavaScript wrappers for them.
We choose to deliberately violate the ES2015 specification and
implement the ArrayBuffer constructor in a way that matches
Firefox and Safari instead.
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
BUG=chromium:565917, v8:4592
TBR=hpayer@chromium.orgR=cbruni@chromium.org
LOG=n
Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
Cr-Commit-Position: refs/heads/master@{#32590}
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#33072}
In a rare edge case, a difference in checks between C++ and
JavaScript lead to an 'illegal access' being thrown by the Date
constructor. This patch harmonizes the checks from both sides.
It's possible that slightly larger dates could be permitted,
as the ECMAScript 2015 specification indicates that +287396-10-12
would be a permissible date in the note in
http://tc39.github.io/ecma262/#sec-extended-years
This patch does not revisit the limit, only clears up the
inconsistency.
BUG=v8:4640
R=cbruni
LOG=Y
Review URL: https://codereview.chromium.org/1545883003
Cr-Commit-Position: refs/heads/master@{#33068}
Reason for revert:
Should be fixed again with this Blink change to add NeedsManualRebaseline
Original issue's description:
> Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of https://codereview.chromium.org/1541233002/ )
>
> Reason for revert:
> [Sheriff] Changes layout tests. Please fix upstream first if intended.
>
> https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
>
> Original issue's description:
> > Use ES2015-style TypedArray prototype chain
> >
> > This patch switches TypedArrays to use the prototype chain described
> > in the ES2015 specification, which adds a %TypedArray% superclass above
> > all individual TypedArray types. Most methods are defined on the
> > superclass rather than the subclasses.
> >
> > In order to prevent a performance regression, a few methods are
> > marked as inline. Inlining might prevent code which was previously
> > monomorphic from becoming polymorphic, and it was specifically
> > applied in places where methods became more polymorphic than before.
> > Tests with realistic workloads would be nice to do before this
> > ships in stable.
> >
> > This patch does not bring TypedArrays up to full spec compliance. In
> > particular, @@species is not yet supported.
> >
> > R=cbruni
> > BUG=v8:4085
> > LOG=Y
> >
> > Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
> > Cr-Commit-Position: refs/heads/master@{#33050}
>
> TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4085
>
> Committed: https://crrev.com/28b55ffd1e32e09aaf42b8bbb407944d4808e07c
> Cr-Commit-Position: refs/heads/master@{#33053}
TBR=caitpotter88@gmail.com,cbruni@chromium.org,machenbach@chromium.org
BUG=v8:4085
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1558663002
Cr-Commit-Position: refs/heads/master@{#33067}
This patch relands a change to ES2015 Promises which brings us closer to
spec compliance. In this new version, a bug which would lose async callstack
data was fixed.
R=adamk
CC=rossberg,caitp
LOG=Y
BUG=v8:3641
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1538663002
Cr-Commit-Position: refs/heads/master@{#33065}
This matches the behavior of JSObject::JSObjectVerify() and seems to be
the current contract for --verify-heap.
BUG=chromium:572590
LOG=n
Review URL: https://codereview.chromium.org/1553463002
Cr-Commit-Position: refs/heads/master@{#33056}
Reason for revert:
[Sheriff] Changes layout tests. Please fix upstream first if intended.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
Original issue's description:
> Use ES2015-style TypedArray prototype chain
>
> This patch switches TypedArrays to use the prototype chain described
> in the ES2015 specification, which adds a %TypedArray% superclass above
> all individual TypedArray types. Most methods are defined on the
> superclass rather than the subclasses.
>
> In order to prevent a performance regression, a few methods are
> marked as inline. Inlining might prevent code which was previously
> monomorphic from becoming polymorphic, and it was specifically
> applied in places where methods became more polymorphic than before.
> Tests with realistic workloads would be nice to do before this
> ships in stable.
>
> This patch does not bring TypedArrays up to full spec compliance. In
> particular, @@species is not yet supported.
>
> R=cbruni
> BUG=v8:4085
> LOG=Y
>
> Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
> Cr-Commit-Position: refs/heads/master@{#33050}
TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4085
Review URL: https://codereview.chromium.org/1554523002
Cr-Commit-Position: refs/heads/master@{#33053}
This patch switches TypedArrays to use the prototype chain described
in the ES2015 specification, which adds a %TypedArray% superclass above
all individual TypedArray types. Most methods are defined on the
superclass rather than the subclasses.
In order to prevent a performance regression, a few methods are
marked as inline. Inlining might prevent code which was previously
monomorphic from becoming polymorphic, and it was specifically
applied in places where methods became more polymorphic than before.
Tests with realistic workloads would be nice to do before this
ships in stable.
This patch does not bring TypedArrays up to full spec compliance. In
particular, @@species is not yet supported.
R=cbruni
BUG=v8:4085
LOG=Y
Review URL: https://codereview.chromium.org/1541233002
Cr-Commit-Position: refs/heads/master@{#33050}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33044}
Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> According to the ES2015 specification, bound functions are exotic
> objects, and thus don't need to be implemented as JSFunctions. So
> we introduce a new JSBoundFunction type to represent bound functions
> and make them optimizable. This already improves the performance of
> calling or constructing bound functions by 10-100x depending on the
> use case because we avoid the crazy dance between JavaScript and C++
> that was implemented in v8natives.js previously.
>
> There's still room for improvement in the performance of actually
> creating bound functions, which is also relevant in practice, but
> we already have a plan how to accomplish that later.
>
> The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}
TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629
Review URL: https://codereview.chromium.org/1552473002
Cr-Commit-Position: refs/heads/master@{#33043}
According to the ES2015 specification, bound functions are exotic
objects, and thus don't need to be implemented as JSFunctions. So
we introduce a new JSBoundFunction type to represent bound functions
and make them optimizable. This already improves the performance of
calling or constructing bound functions by 10-100x depending on the
use case because we avoid the crazy dance between JavaScript and C++
that was implemented in v8natives.js previously.
There's still room for improvement in the performance of actually
creating bound functions, which is also relevant in practice, but
we already have a plan how to accomplish that later.
The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33042}
These constructors always go through C++ at least twice anyway, so
there's not really a point in trying to implement them in JavaScript.
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1548623002
Cr-Commit-Position: refs/heads/master@{#33012}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
Cr-Commit-Position: refs/heads/master@{#32841}
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32857}
We used to flood the handler when preparing for stepping,
even if we may not throw. Instead, we now flood the
handler only when we actually throw.
This also solves an issue with step-next when we throw and
leave the function unexpectedly. In combination with
microtasks, this could cause a crash.
R=mstarzinger@chromium.org
BUG=chromium:568477
LOG=N
Review URL: https://codereview.chromium.org/1527593002
Cr-Commit-Position: refs/heads/master@{#32856}
Reason for revert:
[Sheriff] Layout test changes.
Original issue's description:
> [debugger] debug-evaluate should not not modify local values.
>
> Debug evaluate no longer writes back changes to the replicated
> context chain to the original after execution. Changes to the
> global object or script contexts still stick. Calling functions
> that bind to the original context chain also have their expected
> side effects.
>
> As far as I can tell, DevTools is not interested in modifying
> local variable values. Modifying global variable values still
> works as expected. However, I have not yet removed the old
> implementation, but merely keep it behind a flag.
>
> R=mstarzinger@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
> Cr-Commit-Position: refs/heads/master@{#32841}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1526553003
Cr-Commit-Position: refs/heads/master@{#32845}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32841}
There's at least one case of a time zone alias: Asia/Kathmandu aliases
Asia/Katmandu. ICU seems to normalize to the (deprecated) latter choice.
V8 internationalization choked on this change; this patch interprets
ICU's output more precisely and allows it.
BUG=chromium:487322
R=jungshik,adamk
LOG=Y
Review URL: https://codereview.chromium.org/1509273007
Cr-Commit-Position: refs/heads/master@{#32769}
Without this fix, AssignmentExpressions that happen to be arrow functions
would lead to unbalanced Enter/Leave calls on the fni_, causing thrashing
while trying to infer function names. Symptoms include slow parsing
or OOM (when we create too many AstConsStrings).
To try to keep this from happening in the future, added an RAII helper
class to handle Entering/Leaving FNI state.
The included regression test crashes on my workstation without the patch.
Note that it's too slow in debug mode (as well as under TurboFan),
so I've skipped it there.
BUG=v8:4595
LOG=y
Review URL: https://codereview.chromium.org/1507283003
Cr-Commit-Position: refs/heads/master@{#32768}
This is in preparation for turning the flag off by default.
BUG=chromium:552100
LOG=n
Review URL: https://codereview.chromium.org/1511293002
Cr-Commit-Position: refs/heads/master@{#32729}
- Add JSReceiver::SetIntegrityLevel, with a fast path for regular objects.
- Make Object.{freeze,seal} call this via %Object{Freeze,Seal}, thus no longer
using broken or deprecated functions from v8natives.js.
- Add JSReceiver::OwnPropertyKeys convenience function.
- Reenable harmony/proxies-hash.js test.
R=rossberg
BUG=v8:1543
LOG=N
Review URL: https://codereview.chromium.org/1489423002
Cr-Commit-Position: refs/heads/master@{#32651}
The backing store is only held alive indirectly via the array buffer
referenced by the holder (typed array), so it's not enough to keep the
elements alive (or even just the external pointer loaded from the
elements).
R=mstarzinger@chromium.org,bmeurer@chromium.org
LOG=n
BUG=v8:1827
Review URL: https://codereview.chromium.org/1493983004
Cr-Commit-Position: refs/heads/master@{#32644}
Reason for revert:
[Sheriff] Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3266
Please request rebase upstream first.
Original issue's description:
> Clean up promises and fix an edge case bug
>
> This patch builds on previous Promise spec compliance work by
> cleaning out some old code which existed to support
> Promise.prototype.chain, rephrasing some code to correspond more
> closely to the specification, and removing some incorrect brand
> checking. A test is added for a bug in an edge case which was fixed.
>
> R=rossberg
> BUG=v8:3641
> LOG=Y
>
> Committed: https://crrev.com/1deb89c8fd3cb69714ae0a24e3b5a4e78f6b73b4
> Cr-Commit-Position: refs/heads/master@{#32627}
TBR=rossberg@chromium.org,caitpotter88@gmail.com,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3641
Review URL: https://codereview.chromium.org/1501763004
Cr-Commit-Position: refs/heads/master@{#32629}
This patch builds on previous Promise spec compliance work by
cleaning out some old code which existed to support
Promise.prototype.chain, rephrasing some code to correspond more
closely to the specification, and removing some incorrect brand
checking. A test is added for a bug in an edge case which was fixed.
R=rossberg
BUG=v8:3641
LOG=Y
Review URL: https://codereview.chromium.org/1488783002
Cr-Commit-Position: refs/heads/master@{#32627}
Reason for revert:
Blocks the roll:
https://codereview.chromium.org/1497763004/
Original issue's description:
> [es6] Correctify and unify ArrayBuffer and SharedArrayBuffer constructors.
>
> The ArrayBuffer and SharedArrayBuffer constructors should raise an
> exception when called with no arguments or undefined length. Also
> unified the ArrayBuffer and SharedArrayBuffer implementations as C++
> builtins, and removed some (now) obsolete runtime entries.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
> Cr-Commit-Position: refs/heads/master@{#32590}
TBR=yangguo@chromium.org,cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1501673002
Cr-Commit-Position: refs/heads/master@{#32606}
The ArrayBuffer and SharedArrayBuffer constructors should raise an
exception when called with no arguments or undefined length. Also
unified the ArrayBuffer and SharedArrayBuffer implementations as C++
builtins, and removed some (now) obsolete runtime entries.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#32590}
non-constructors are not allowed to have initial maps. The optimizing compilers used to add initial maps unconditionally to functions used as right-hand-side in instanceof.
BUG=
Review URL: https://codereview.chromium.org/1490003003
Cr-Commit-Position: refs/heads/master@{#32497}
This fixes a corner-case in redeclaration handling, where the ES2015
early error case got mixed up with legacy const handling in the parser.
Redeclaration using ES2015 'let' and 'const' should be early errors,
but legacy 'const' redeclaration has historically been a runtime error,
and should stay that way until legacy 'const' is gone.
The fix here is uglier than it might be due to
https://code.google.com/p/v8/issues/detail?id=4577, which keeps us
from simplifying the mess of if/else-if in the current code.
BUG=v8:4576
LOG=n
Review URL: https://codereview.chromium.org/1485943002
Cr-Commit-Position: refs/heads/master@{#32429}
This replaces internal GetConstructorName with toStringTag, .constructor's name
and class_name. This entirely changes how the name is computed for use in
devtools.
BUG=chromium:529177
LOG=n
Review URL: https://codereview.chromium.org/1435273002
Cr-Commit-Position: refs/heads/master@{#32374}
We currently assume that all prototype maps are stable, which is
not guaranteed for certain keyed access patterns. So we explicitly
disallow optimizing the element access there for now.
BUG=chromium:557807, v8:4470
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1456973004
Cr-Commit-Position: refs/heads/master@{#32101}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
When adding properties to the result object, that object's prototype chain should be ignored.
Review URL: https://codereview.chromium.org/1458873002
Cr-Commit-Position: refs/heads/master@{#32085}
This fixes the array literal expression stack tracking in the presence
of spread expressions. Deoptimization within a spread expression was
borked.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-deopt-in-array-literal-spread
Review URL: https://codereview.chromium.org/1455953002
Cr-Commit-Position: refs/heads/master@{#32079}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1453733002
Cr-Commit-Position: refs/heads/master@{#32050}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1452193003
Cr-Commit-Position: refs/heads/master@{#32048}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1451423002
Cr-Commit-Position: refs/heads/master@{#32047}
With do-expressions any expression used as a case label can turn into an
OSR entry-point. This means the value being switched over is renamed to
an OSR value and needs to be reloaded from the environment at each case.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-case-label
Review URL: https://codereview.chromium.org/1438123007
Cr-Commit-Position: refs/heads/master@{#31986}
This makes sure that inlining a constructor call to a function which
cannot be used as a constructor (e.g. strong mode function) still does
throw correctly when the implicit receiver is created.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-inline-strong-as-construct
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1447443002
Cr-Commit-Position: refs/heads/master@{#31982}
JSRegExp's properties backing stores must not be shared.
BUG=chromium:548580
LOG=N
Review URL: https://codereview.chromium.org/1429743006
Cr-Commit-Position: refs/heads/master@{#31867}
We forgot to add the number of arguments parameter in
JSFrameSpecialization, which was added before the context.
R=jarin@chromium.org
BUG=chromium:552304
LOG=n
Review URL: https://codereview.chromium.org/1429233004
Cr-Commit-Position: refs/heads/master@{#31856}
This fixes receiver conversion since the Call builtin does it correctly.
BUG=v8:4526
LOG=n
Review URL: https://codereview.chromium.org/1407373007
Cr-Commit-Position: refs/heads/master@{#31823}
The %_CallFunction doesn't implement the call sequence properly, it
doesn't do the receiver wrapping, nor does it check for
classConstructor. Also the eager deoptimization for %_CallFunction was
seriously b0rked (we must have been lucky with TurboFan so far).
R=yangguo@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1419813010
Cr-Commit-Position: refs/heads/master@{#31821}
Original issue's description:
> [es6] Fix Function and GeneratorFunction built-ins subclassing.
>
> BUG=v8:3101, v8:3330
> LOG=Y
>
> Committed: https://crrev.com/99e7f872d3d0a5fb799dcbafb05537cda491314a
> Cr-Commit-Position: refs/heads/master@{#31708}
The problem was in another CL, this is a clean reland with improved tests.
BUG=v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1415683007
Cr-Commit-Position: refs/heads/master@{#31756}
This fixes [NAMED|KEYED]_SUPER_PROPERTY_CALL to perform a method call
instead of a function call. The difference is visible for sloppy mode
targets that convert primitive receivers.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4525
BUG=v8:4525
LOG=n
Review URL: https://codereview.chromium.org/1419173004
Cr-Commit-Position: refs/heads/master@{#31664}
This refactors the handling of calls of type Call::PROPERTY_CALL to
super properties in AstGraphBuilder::VisitCall. It ensures that the
operand stack is kept in sync with full-codegen so that deopts while
evaluating sub-expressions behave as expected.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4521
BUG=v8:4521
LOG=n
Review URL: https://codereview.chromium.org/1426893003
Cr-Commit-Position: refs/heads/master@{#31652}
This fixes a missing SSA-renaming of the callee value used in the frame
state of a call node. An OSR-entry within do-expressions contained in
one of the argument expression can trigger that renaming.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-crbug-546968
BUG=chromium:546968
LOG=n
Review URL: https://codereview.chromium.org/1430483002
Cr-Commit-Position: refs/heads/master@{#31613}
Previously ChangeLowering would always box float64 values when going to
tagged representation, but that introduces a lot of deoptimizer loops
and polymorphism into TurboFan, which is unfortunate and unnecessary.
This adds some logic to ChangeFloat64ToTagged to try harder to create a
Smi when going from Float64 to Tagged, instead of always allocating a
HeapNumber. This might need some additional tweaking, but at least it
makes it possible to start comparing TurboFan and Crankshaft for some
regular JavaScript.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1420913003
Cr-Commit-Position: refs/heads/master@{#31609}
This fixes the representation type for values in JSArray::length fields
when JSNativeContextSpecialization lowers loads. Only arrays with fast
elements kind are guaranteed to have a Smi represented length.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-4515
BUG=v8:4515, v8:4493, v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1410393006
Cr-Commit-Position: refs/heads/master@{#31558}
It is not always safe to allocate new heap objects in the JSGraph. We
might have to revisit this later once we do the canonicalization for
HeapConstants.
R=jarin@chromium.org
BUG=chromium:545364
LOG=n
Review URL: https://codereview.chromium.org/1413373002
Cr-Commit-Position: refs/heads/master@{#31421}
This patch refactors array methods to have the
InnerArray{Map,Filter} methods convert to a GlobalArray
rather than the callers.
BUG=chromium:544991
R=yangguo,adamk
CC=mstarzinger,jochen
LOG=Y
Review URL: https://codereview.chromium.org/1408213004
Cr-Commit-Position: refs/heads/master@{#31403}
This introduces an explicit lazy bailout. It is wrapped in the call
node, mostly because the lazy deoptimization processing is married
to the call processing in the instruction selector and the code generator.
It is still a terrible hack.
R=bmeurer@chromium.org,mstarzinger@chromium.org
BUG=chromium:543994,v8:4195
LOG=n
Review URL: https://codereview.chromium.org/1412443003
Cr-Commit-Position: refs/heads/master@{#31353}
This is in preparation to enabling --turbo-inlining by default, fixing
various issues when general purpose inlining is running against our
entire test suite.
R=bmeurer@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1407533004
Cr-Commit-Position: refs/heads/master@{#31294}
For an edge case like the following in sloppy mode
with ({}) function f() {}
a lexical scope needs to be created around the body in order
to hold the function declaration, so it can be hoisted according
to a loose interpretation of Annex B 3.3 (loose because ES2015
does not permit a function declaration as the body of a with
statement). This patch adds that scope.
BUG=chromium:542100
LOG=N
R=adamk
Review URL: https://codereview.chromium.org/1404803002
Cr-Commit-Position: refs/heads/master@{#31269}
This patch fixes an obscure edge case for functions defined as the
direct body of a for-of/for-in loop, such as the following:
for (foo in []) function foo() { return foo; }
Here, the first occurrence of foo should point to the outer scope;
however, before this patch, it pointed to the inner foo in an
invalid way which caused an assertion about the scope chain to fail.
This patch fixes the scope chain by inserting an extra scope for
the body of the loop, not including the header.
BUG=chromium:542099
LOG=N
R=rossberg
Review URL: https://codereview.chromium.org/1396663004
Cr-Commit-Position: refs/heads/master@{#31268}
The flag for deactivating break points also affects stepping, since both
are implemented via debug break slots. Fixing this by introducing a new
flag solely responsible for deactivating actual break points.
R=mvstanton@chromium.org
BUG=chromium:119800
LOG=N
Review URL: https://codereview.chromium.org/1402913002
Cr-Commit-Position: refs/heads/master@{#31236}
Looking up 'name' and 'message' properties at the same time and loading
the properties later can cause assertion failure if one of the properties
is an accessor and calling it changes the holder map. That may invalidate
the other lookup.
R=jkummerow@chromium.org
BUG=chromium:542101
LOG=N
Review URL: https://codereview.chromium.org/1403923002
Cr-Commit-Position: refs/heads/master@{#31229}
Clusterfuzz testing discovered that sloppy-mode block-scoped function
declarations introduce lexically-scoped variables in scopes that were
thrown away under the expectation that no lexically-scoped variables
were introduced. These cases are:
for (;;) function foo() {}
for (x in y) function foo() {}
This patch ensures that a block is created in those cases to hold the
lexically scoped variable. Usually, scope analysis should discover that
that block is not important, and it should not have a runtime
representation.
BUG=chromium:536750,chromium:536751
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1382123002
Cr-Commit-Position: refs/heads/master@{#31109}
This name makes it clear that the flag (also the variant in the Compiler)
is talking about specializing to the function context instead of i.e. the
native context.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1372513003
Cr-Commit-Position: refs/heads/master@{#30934}
Whenever a generalization is computed, the inputs must be checked for being cleared, and if they are, the generalization must be Type::Any.
Hopefully this fixes Chromium issue 527994 as well.
BUG=v8:4325,chromium:527994
LOG=n
Review URL: https://codereview.chromium.org/1361103002
Cr-Commit-Position: refs/heads/master@{#30887}
This CL also renames wrongly named test for v8:4173.
BUG=v8:4121
LOG=Y
Review URL: https://codereview.chromium.org/1353363002
Cr-Commit-Position: refs/heads/master@{#30879}
The ES6 specification says that "Built-in functions that are ECMAScript
function objects must be strict mode functions", which in particular
means that you can never test for them using the "caller" field of a
sloppy mode function.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=mstarzinger@chromium.org
BUG=v8:105
LOG=n
Review URL: https://codereview.chromium.org/1347663002
Cr-Commit-Position: refs/heads/master@{#30750}
The assumption that every function body produces a value does not hold
for functions that e.g. unconditionally throw or endlessly loop. This
fixes the inlining logic to handle such cases.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-530598
BUG=chromium:530598
LOG=n
Review URL: https://codereview.chromium.org/1333193005
Cr-Commit-Position: refs/heads/master@{#30738}
When looking up a special accessor for known TypedArray fields
("length", "byteLength", "byteOffset"), consider the entire prototype
chain, not only the direct prototype.
This allows subclasses of TypedArrays to benefit from fast specialized
accesses.
Review URL: https://codereview.chromium.org/1313493005
Cr-Commit-Position: refs/heads/master@{#30678}
Update the consolidated load case to carefully chose the load mode
based on the consolidated elements kind.
BUG=v8:4380
LOG=N
Review URL: https://codereview.chromium.org/1329793003
Cr-Commit-Position: refs/heads/master@{#30659}
This makes the C++ fallback implementations for the two intrinsics,
%Arguments and %ArgumentsLength composable with respect to inlining.
Using deoptimization information gives us accurate data here.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-4374
BUG=v8:4374
LOG=n
Review URL: https://codereview.chromium.org/1328363002
Cr-Commit-Position: refs/heads/master@{#30654}
This switches Isolate::ComputeLocation to use baseline code when
computing message locations. This unifies locations between optimized
and non-optimized code by always going through the FrameSummary for
location computation.
R=bmeurer@chromium.org
TEST=message/regress/regress-4266
BUG=v8:4266
LOG=n
Review URL: https://codereview.chromium.org/1331603002
Cr-Commit-Position: refs/heads/master@{#30635}
- Move fast paths from builtins.cc ArraySlice to ElementsAccessor
- Handle more argument types in the fast path
BUG=
Review URL: https://codereview.chromium.org/1321773002
Cr-Commit-Position: refs/heads/master@{#30471}
This patch changes the switch scope desugaring to create blocks which
propagate their 'return value' for eval.
BUG=v8:4399
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1309303006
Cr-Commit-Position: refs/heads/master@{#30454}
Switch statements introduce their own scope for cases, but this scope
is not necessarily executed in order, as the following function shows:
switch (x) {
case 1:
let y = 1;
case 2:
y = 2;
case 3:
print(y);
}
If x = 2 or x = 3, the code should throw a ReferenceError. However,
FullCodeGen's hole check elimination used the simple algorithm of
assuming that if the initializer was in the same scope, then it was
reached before the use, and therefore the hole check could be
eliminated.
This patch adds an extra bit to scopes, to track if they may
nonlinearly. The parser marks the scope that switch introduces as
nonlinear. FullCodeGen does not eliminate the hole check from
a scope which is nonlinear. This patch refactors FullCodeGen to
put the hole check elimination in one place, rather than in each
backend.
BUG=v8:3926
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1312613003
Cr-Commit-Position: refs/heads/master@{#30453}
This fixes broken dynamic hole-checks for the temporal dead zone of
non-initializing assignments to {let} and {const} declared variables.
Also note that this exemplifies a case where the dynamic check for such
assignments to {let} declared variables can no longer be elided as the
comment suggested.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4388
BUG=v8:4388
LOG=n
Review URL: https://codereview.chromium.org/1318693002
Cr-Commit-Position: refs/heads/master@{#30375}
The previous hack with HInstanceOfKnownGlobal was not only slower,
but also very brittle and required a lot of weird hacks to support it. And
what's even more important it wasn't even correct (because a map check
on the lhs is never enough for instanceof).
The new implementation provides a sane runtime implementation
for InstanceOf plus a fast case in the InstanceOfStub, combined with
a proper specialization in the case of a known global in CrankShaft,
which does only the prototype chain walk (coupled with a code
dependency on the known global).
As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf
implementation.
BUG=v8:4376
LOG=y
Review URL: https://codereview.chromium.org/1304633002
Cr-Commit-Position: refs/heads/master@{#30342}
The ES2015 specification for switch statements 13.12.11 specifies that
they get their own lexical scope. This patch introduces such a scope
through a complex desugaring in terms of blocks, done so that Crankshaft
does not have to be updated to support multiple constructs providing
scopes.
Recommitting this patch after a bug fix in Crankshaft to allow a
desugaring with certain elements missing a source location:
https://codereview.chromium.org/1313443002
BUG=v8:4377
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1309163003
Cr-Commit-Position: refs/heads/master@{#30340}
The simulator uses a separate JS stack, exhaustion of the C stack
however is not caught by JS limit checks. This change now lowers the
limit of the JS stack accordingly on function calls.
R=mvstanton@chromium.org
BUG=chromium:522380
TEST=mjsunit/regress/regress-crbug-522380
LOG=n
Review URL: https://codereview.chromium.org/1314623002
Cr-Commit-Position: refs/heads/master@{#30334}
Reason for revert:
Breaks cctest/test-cpu-profiler/SourceLocation on nosnap
Original issue's description:
> Add a separate scope for switch
>
> The ES2015 specification for switch statements 13.12.11 specifies that
> they get their own lexical scope. This patch introduces such a scope
> through a complex desugaring in terms of blocks, done so that Crankshaft
> does not have to be updated to support multiple constructs providing
> scopes.
>
> BUG=v8:4377
> LOG=Y
> R=adamk
>
> Committed: https://crrev.com/9edbc1f21eb1050cabbe3b8bc9aebf89ada7ebd7
> Cr-Commit-Position: refs/heads/master@{#30314}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4377
Review URL: https://codereview.chromium.org/1309043004
Cr-Commit-Position: refs/heads/master@{#30316}
The parser has special behavior with respect to the bindings
of inner functions in sloppy mode which are not at the top
level of scopes. This behavior should be turned off when the
--harmony-sloppy-function flag is set, as lexical scoping
rules are used instead. Previously, the incorrect flag
--harmony-sloppy was used, resulting in a crashing bug.
BUG=chromium:520029
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1303033003
Cr-Commit-Position: refs/heads/master@{#30315}
The ES2015 specification for switch statements 13.12.11 specifies that
they get their own lexical scope. This patch introduces such a scope
through a complex desugaring in terms of blocks, done so that Crankshaft
does not have to be updated to support multiple constructs providing
scopes.
BUG=v8:4377
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1293283002
Cr-Commit-Position: refs/heads/master@{#30314}
This avoids many back-and-forth calls to the runtime.
This also slightly changes the way we avoid getters. Previously, we circumvent getting the name property of ReferenceError, SyntaxError and TypeError due to crbug/69187 (in order to avoid leaking information from those errors through a 'name' getter installed on their prototypes). Now we do that for all errors created by V8.
R=jkummerow@chromium.org, rossberg@chromium.org
BUG=crbug:513472, crbug:69187
LOG=N
Review URL: https://codereview.chromium.org/1281833002
Cr-Commit-Position: refs/heads/master@{#30105}
To avoid tanking context startup performance, only the actual installation of the
JS-exposed API is flag-guarded. The remainder of the implementation still
resides in the snapshot.
Review URL: https://codereview.chromium.org/1257063003
Cr-Commit-Position: refs/heads/master@{#30017}
This introduces a CopyFixedArrayAndGrow method on Factory that takes
the "grow amount" instead of the "new size" as an argument. The new
interface is safer because it allows for mutations by the GC that
potentially trim the source array.
This also fixes a bug in SharedFunctionInfo::AddToOptimizedCodeMap
where the aformentioned scenario led to unused entries within the
optimized code map.
Note that FixedArray::CopySize is hereby deprecated because it is
considered unsafe and should no longer be used.
R=hpayer@chromium.org
TEST=mjsunit/regress/regress-crbug-513507
BUG=chromium:513507
LOG=n
Review URL: https://codereview.chromium.org/1255173006
Cr-Commit-Position: refs/heads/master@{#30012}
The calculation now takes into account the size of the arguments object
if it is present in the optimized frame.
(Yang, many thanks for the awesome repro!)
BUG=chromium:514362
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1264483008
Cr-Commit-Position: refs/heads/master@{#29973}
When the main thread terminates, it forcibly terminates all Worker threads.
When this happens, the threads objects were only half-created; they had a
JavaScript Worker object, but not a C++ worker object.
This CL fixes that bug, as well as some other fixes:
* Signatures on Worker methods
* Use SetAlignedPointerFromInternalField instead of using an External.
* Remove state_ from Worker. Simplify to atomic bool running_.
BUG=chromium:511880
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1255563002
Cr-Commit-Position: refs/heads/master@{#29911}
When a prototype object migrates from a slow to a fast map, where the slow map
was registered as a user of its own prototype, then the registration must be
transferred to the new map (just like MigrateToMap does for all other cases).
BUG=chromium:513602
LOG=y
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/1263543004
Cr-Commit-Position: refs/heads/master@{#29898}
Previous to this CL, ICs used a slightly different code idiom
to get to C++ code from generated code than runtime intrinsics,
using an IC_Utility class that in essence provided exactly
the same functionality as Runtime::FunctionForId, but in its
own quirky way.
This CL unifies the two mechanisms, folding IC_Utility
away by making all IC entry points in C++ code, e.g. IC
miss handlers, full-fledged runtime intrinsics. This makes
it possible to eliminate a bunch of ad-hoc declarations and
adapters that the IC system had to needlessly re-invent.
As a bonus and the original reason for this yak-shave:
IC-related C++ runtime functions are now callable from
TurboFan.
Review URL: https://codereview.chromium.org/1248303002
Cr-Commit-Position: refs/heads/master@{#29811}
A sloppy mode eval call that establishes strict mode will leak that strictness
into the sloppy surrounding scope on recompile. This changes the structure
of the type feedback vector for the function and crashes follow.
The fix is straightforward.
BUG=491536, 503565
LOG=N
Review URL: https://codereview.chromium.org/1231343003
Cr-Commit-Position: refs/heads/master@{#29671}
--debug-code causes full-codegen on arm64 to emit different number
of calls, which confuses the debugger when on-stack replacing code
with recompiled debug version on-stack.
BUG=chromium:507070
TBR=mstarzinger@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1228353004
Cr-Commit-Position: refs/heads/master@{#29638}
The new implemtation counts the number of calls (or continuations)
before the PC to find the corresponding PC in the new code.
R=mstarzinger@chromium.org
BUG=chromium:507070
LOG=N
Review URL: https://codereview.chromium.org/1235603002
Cr-Commit-Position: refs/heads/master@{#29636}
When quit() is called, d8 shell exits without cleanup. If a worker is running,
it might be holding the context_mutex_, which if destroyed will DCHECK.
BUG=4279
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1231473002
Cr-Commit-Position: refs/heads/master@{#29557}
This one occurred when serializing an object. When the property getter threw an
exception, that value was skipped, but the property count wasn't updated. The
deserializer then tried to deserialize the wrong value.
BUG=chromium:506549
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1220193004
Cr-Commit-Position: refs/heads/master@{#29541}
Smi immediates are not supported, so instructions with Smi representations need their constants in a register. LAddI has already been doing this. The manifestation of the bug was that an operation would compute 0 instead of the correct result.
BUG=chromium:478612
LOG=y
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1224623017
Cr-Commit-Position: refs/heads/master@{#29529}
The context constant cannot be materialized from the frame when we are
compiling for OSR, because the context spill slot contains the current
instead of the outermost context in full-codegen.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1220013003
Cr-Commit-Position: refs/heads/master@{#29472}
This is more consistent with the DOM API, and is clearer w.r.t. which values
are available in the lexical environment of the Worker.
BUG=chromium:497295
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1218553004
Cr-Commit-Position: refs/heads/master@{#29426}
v8::Internal::List will DCHECK when indexing out of the array, even if just to
get the address, and the value is never used. So this construct will fail:
memcpy(p, &data[0], length);
When data is empty and length is 0.
BUG=chromium:505778
R=mstarzinger@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1216853003
Cr-Commit-Position: refs/heads/master@{#29388}
This makes sure that the exit control flow that merges the try-block
with the catch-block after a try-catch-statement creates a new merge
node in cases where it has to. Otherwise dangling phi nodes might have
the wrong number of value inputs.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-505354
BUG=chromium:505354
LOG=N
Review URL: https://codereview.chromium.org/1213183003
Cr-Commit-Position: refs/heads/master@{#29362}
Dumb typo introduced in refs/heads/master@{#29306}. I thought I was turning on
report_exceptions in Shell::ExecuteString, but instead I turned on print_result
(which assumes an interactive debugger and a HandleScope for the
utility_context_).
BUG=chromium:504727,chromium:504728
R=mstarzinger@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1219563002
Cr-Commit-Position: refs/heads/master@{#29350}
Note that prior to having canonical shared function infos, this has
been a source of duplicate shared function infos.
R=bmeurer@chromium.org
BUG=chromium:504787
LOG=N
Review URL: https://codereview.chromium.org/1209383002
Cr-Commit-Position: refs/heads/master@{#29326}
The issue is that Worker.prototype.terminate was deleting the C++ Worker
object, and then Worker.prototype.getMessage was trying to read messages from
the queue.
The simplest solution is to keep workers in a zombie state when they have been
terminated. They won't be reaped until Shell::CleanupWorkers is called.
I've also fixed some threading issues with Workers:
* Workers can be created by another Worker, so the Shell::workers_ variable
must be protected by a mutex.
* An individual Worker can typically only be accessed by the isolate that
created it, but the main thread can always terminate it, so the Worker::state_
must be accessed in a thread-safe way.
BUG=chromium:504136
R=jochen@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1208733002
Cr-Commit-Position: refs/heads/master@{#29306}
Shell::SerializeValue was using a HandleScope, but was also storing Handles in
an ObjectList. The ObjectList handles would persist after the function had
returned, but will have already been destroyed by the HandleScope, so there is
a use-after-free.
This change removes the HandleScope in Shell::SerializeValue and relies on the
caller's HandleScope.
BUG=chromium:503968
R=jochen@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1211433003
Cr-Commit-Position: refs/heads/master@{#29265}
Speculative revert in the hopes of fixing serializer crashes seen in canary.
This reverts commit c166945083, as well as
followup change "Do not look for existing shared function info when compiling a new script."
(commit 7c43967bb7).
BUG=chromium:503552,v8:4132
TBR=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1207583002
Cr-Commit-Position: refs/heads/master@{#29241}
Each Script object now keeps a WeakFixedArray of SharedFunctionInfo
objects created from this script.
This way, when compiling a function, we do not create duplicate shared
function info objects when recompiling with either compiler.
This fixes a class of issues in the debugger, where we set break points
on one shared function info, but functions from duplicate shared function
infos are not affected.
LOG=N
BUG=v8:4132
Review URL: https://codereview.chromium.org/1183733006
Cr-Commit-Position: refs/heads/master@{#29151}
