Empty Array literals are amongst the most commonly used literal types on our
top25 page list. Using a custom bytecode we can drop the boilerplate for empty
Array literals alltogether. However, we still need a proper AllocationSite to
track ElementsKind transitions.
Bug: v8:6211, chromium:746935
Change-Id: I891eaa778e4e81e138e483a65f04ae00ae30bd28
Reviewed-on: https://chromium-review.googlesource.com/580932
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46875}
A Phi is necessary to carry the ElementsKind forward in case transitions
are taken.
Bug: chromium:747075
Change-Id: I9d9d66b0219fe3f67d08536f4d478ee300c76acb
Reviewed-on: https://chromium-review.googlesource.com/583090
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46852}
Now that literal allocation is inlined, it is possible to optimize out regexp
literal allocation completely. If a lazy deopt is triggered in that situation,
the deoptimizer needs to know how to materialize regexp objects.
Bug: v8:6605,v8:6556,chromium:747825
Change-Id: Id491053f8e64fec16540efbfdc6c7c524da3e080
Reviewed-on: https://chromium-review.googlesource.com/582609
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46837}
... in order to avoid the need to update field types through elements
kind transitions.
Bug: chromium:738763, chromium:745844
Change-Id: I9f0e7f321e7f44ab5b36c06dd4c5633611370807
Reviewed-on: https://chromium-review.googlesource.com/581647
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46830}
This reverts commit 6e27386d68.
Reason for revert: There will be another much simpler and
back-mergeable fix.
Original change's description:
> Reland "[runtime] Add shortcuts for elements kinds transitions."
>
> This is a reland of b90e83f5da
> Original change's description:
> > [runtime] Add shortcuts for elements kinds transitions.
> >
> > The shortcuts ensure that field type generalization is properly
> > propagated in the transition graph.
> >
> > Bug: chromium:738763
> > Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
> > Reviewed-on: https://chromium-review.googlesource.com/567992
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46622}
>
> Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
> Change-Id: I93974e3906b2c7710bd525f15037a2dd97f263ad
> Reviewed-on: https://chromium-review.googlesource.com/575227
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46759}
TBR=ulan@chromium.org,jkummerow@chromium.org,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
Change-Id: I203dc748c47db554e0a86d61f0e2b7b8b96f2370
Reviewed-on: https://chromium-review.googlesource.com/581547
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46826}
Inlining heuristics in Turbofan used ast node count. Bytecode size
is a better approximation of the size of the graph than the
ast node count. This cl changes the heuristics to use the bytecode
size instead. Also removing the ast_node_count filed in the shared
function info. It was used only for the inlining heuristics.
Also removed the max_inlined_source_size flag which is no longer used.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I8a2d2509c8e8d2779b33b817bb217de203d54ec3
Reviewed-on: https://chromium-review.googlesource.com/570055
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46771}
This is a reland of b90e83f5da
Original change's description:
> [runtime] Add shortcuts for elements kinds transitions.
>
> The shortcuts ensure that field type generalization is properly
> propagated in the transition graph.
>
> Bug: chromium:738763
> Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
> Reviewed-on: https://chromium-review.googlesource.com/567992
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46622}
Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
Change-Id: I93974e3906b2c7710bd525f15037a2dd97f263ad
Reviewed-on: https://chromium-review.googlesource.com/575227
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46759}
The test for CanTreatHoleAsUndefined on keyed element access was
checking for stability of Object.prototype and Array.prototype and
even adding stability dependencies on both, which is too restrictive
and leads to unnecessary deoptimizations (and might disable further
optimization of the keyed access depending on the state of the
prototype objects during optimization). This was not intended and
is considered a (performance) bug.
Instead use the correct approach of checking whether the receiver's
prototype is one of the current Object.prototype or Array.prototype
objects (since the Array protector works isolate-wide), and then
check the Array protector and install an appropriate code dependency
on the protector only.
Bug: v8:6607
Change-Id: I0bcfe32813ca3693e7b22de31b03edb3509d0a27
Reviewed-on: https://chromium-review.googlesource.com/574849
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46743}
The code was already there, but there was a bug in it: Because of the
missing reference, we were only updating a *copy* of the signature map,
hence the update had no effect.
This intentially is a minimal CL, in order to allow for easy
backmerging.
More mitigations and tests are coming in a separate CL.
R=titzer@chromium.org
Change-Id: Ifb462093f4b8f4d5380b6774636537c67c2b676c
Reviewed-on: https://chromium-review.googlesource.com/570278
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46664}
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.
This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.
BUG=v8:5203, v8:6409, v8:6589
Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
It's ok that the instance of the called code object is different from
the caller instance. This happens if one instance calls an exported
function of another instance.
R=ahaas@chromium.org
Bug: chromium:739768
Change-Id: I6afa8332a9b33fe32e9332cdca573053f058421d
Reviewed-on: https://chromium-review.googlesource.com/568494
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46624}
The shortcuts ensure that field type generalization is properly
propagated in the transition graph.
Bug: chromium:738763
Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
Reviewed-on: https://chromium-review.googlesource.com/567992
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46622}
This correctly types values loaded via {LoadElement} nodes from arrays
of HOLEY_DOUBLE_ELEMENTS elements kind as {Type::NumberOrHole}. Even
though "the hole" is still encoded as a tagged NaN, the type system
still needs to consider it as a potential hole value.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-736575
BUG=chromium:736575
Change-Id: Ib869284900a4affb2ddaa1d2a96df9443dba6921
Reviewed-on: https://chromium-review.googlesource.com/567180
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46620}
When we abort preparsing, we have to reset the Scope state, to ensure
re-parsing will leave us in the proper Zone. Resetting of rare_data_
was missing, causing this to fail in some cases.
Bug: chromium:740803
Change-Id: I7ce70f9c4670eaf1b76745ae8231eb95625b0f4b
Reviewed-on: https://chromium-review.googlesource.com/568784
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46607}
By creating the boilerplate only on the second instantiation we cannot
propagate back the elements transitions early enough. The resulting literals
would change the initial ElementsKind one step too late and already pollute
ICs that went to monomorphic state.
- Disable lazy AllocationSites for literals containing arrays
- Introduce new ComplexLiteral class to share code between ObjectLiteral
and ArrayLiteral
- RegexpLiteral now no longer needs a depth_ field
Bug: v8:6517, v8:6519, v8:6211
Change-Id: Ia88d1878954e8895c3d00a7dda8d71e95bba005c
Reviewed-on: https://chromium-review.googlesource.com/563305
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46603}
JSFunction::SetName can fail if it tries to create a string with
length > String::kMaxLength (either by prepending "set "/"get " or
by surrounding a Symbol descriptor with "["/"]").
This patch propagates that exception to the surrounding code rather
than CHECK-failing.
Bug: chromium:740398
Change-Id: I394943af481f3147387dd82ec5862d7071d57827
Reviewed-on: https://chromium-review.googlesource.com/566092
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46601}
This makes sure the inline allocation of generator objects only shrinks
initial maps when slack tracking is actually in progress. Shrinking all
unused properties unconditionally is bogus because instances using them
might have become unreachable and collected by the GC.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-741078
BUG=chromium:741078
Change-Id: Iaf2f08a4fa82c820a945bf012d24c760a6b4f514
Reviewed-on: https://chromium-review.googlesource.com/567982
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46585}
This introduces 2^16 as an upper limit for the allowed value range of a
table switch on all architectures. It also fixes several overflows in
the table size calculation.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-736633
BUG=chromium:736633
Change-Id: I931bd226c99eb8a1ae1770c159fc314ff650bf57
Reviewed-on: https://chromium-review.googlesource.com/566829
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46575}
Previously (since f0e95769), this toLowerCase fast-path assumed
it would only see one-byte flat contents. Unfortunately, it's
possible to have a one-byte sliced string that has a two-byte parent.
This CL ensures that String.p.toLowerCase handles such cases
correctly.
BUG=chromium:736451
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iae056b3db5535bb5665439a5cc8282a51571a548
Reviewed-on: https://chromium-review.googlesource.com/565559
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46574}
This fixes the lowering of Reflect.getPrototypeOf and friends to not
perform a [[ToObject]] coercion, but bailout instead. We ensure to
exclude primitive values from the lowering. This makes the lowering
uniform between "Reflect.getPrototypeOf" and "Object.getPrototypeOf".
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-740116
BUG=chromium:740116
Change-Id: If986ee2a3ae4e8f1fd227bdeb4668f523b0dea84
Reviewed-on: https://chromium-review.googlesource.com/565295
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46556}
This improves the general Array constructor call performance (w/o
usable AllocationSite feedback) in TurboFan by ~2x, i.e. for example
invoking the Array constructor like this
var a = Array.call(undefined, n);
instead of
var a = Array(n);
such that the CallIC doesn't know that it's eventually calling the
Array constructor.
It also thus changes the single argument Array constructor to always
return holey arrays. Previously the single argument case for the Array
constructor was somehow trying to dynamically detect 0 and in that case
returned a packed array instead of a holey one. That adds quite a lot
of churn, and doesn't seem to be very useful, especially since this
might lead to unnecessary feedback pollution later.
R=mvstanton@chromium.org
Bug: v8:2229, v8:5269, v8:6399
Change-Id: I3d7cb9bd975ec0e491e3cdbcf1230185cfd1e3de
Reviewed-on: https://chromium-review.googlesource.com/565721
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46538}
The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
This patch renames the FAST elements kinds as follows:
- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
The following exceptions are left intact, for lack of a better name:
- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS
This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.
R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
This reverts commit 1520a8518a.
Reason for revert: This CL does not do what it should. All tasks which access the isolate have to be cancelable to guarantee that the isolate still exists when the task is executed. Foreground compilation tasks access the isolate, so they cannot be just normal tasks.
Original change's description:
> [wasm] Run foreground compilation tasks as normal tasks
>
> This CL makes foreground compilation tasks normal (i.e. not cancelable)
> again, because otherwise a deadlock can happen. I think the reason why
> the foreground tasks were cancelable was to make sure that all tasks
> either finish correctly or get canceled. However, since the isolate can
> only shut down on the main thread, this means that the foreground task
> should have already finished when the isolate shuts down, or it should
> not have started at all. I reordered the deletion of the AsyncCompileJob
> though to make sure that an AsyncCompileJob is removed from
> CompilationManager before its promise is resolved.
>
> Here is the deadlock: The JS code which is executed after a promise is
> resolved is executed within the task which resolves the promise. In case
> of async compilation this means that some JS code is executed within a
> CompileTask. In JS, the shutdown of the isolate can be triggered. During
> the shutdown of the isolate, the CancelableTaskManager waits for all
> registered cancelable tasks to complete, including the CompileTask of
> async compilation. This means that the CancelableTaskManager waits for
> itself to finish, which is a deadlock.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
> Reviewed-on: https://chromium-review.googlesource.com/554733
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46343}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I60fab90b46d70c703d827816503e7e23b8c50251
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558284
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46353}
This CL makes foreground compilation tasks normal (i.e. not cancelable)
again, because otherwise a deadlock can happen. I think the reason why
the foreground tasks were cancelable was to make sure that all tasks
either finish correctly or get canceled. However, since the isolate can
only shut down on the main thread, this means that the foreground task
should have already finished when the isolate shuts down, or it should
not have started at all. I reordered the deletion of the AsyncCompileJob
though to make sure that an AsyncCompileJob is removed from
CompilationManager before its promise is resolved.
Here is the deadlock: The JS code which is executed after a promise is
resolved is executed within the task which resolves the promise. In case
of async compilation this means that some JS code is executed within a
CompileTask. In JS, the shutdown of the isolate can be triggered. During
the shutdown of the isolate, the CancelableTaskManager waits for all
registered cancelable tasks to complete, including the CompileTask of
async compilation. This means that the CancelableTaskManager waits for
itself to finish, which is a deadlock.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
Reviewed-on: https://chromium-review.googlesource.com/554733
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46343}
This mostly reverts commit c503b80595 but fixes
an issue where literals would always be pretenured on first instantiation.
As a cleanup we pass in a PretenureFlag instead of using the FeedbackVector as
indicator.
Bug: v8:6211
Change-Id: Id328552620e33f5083519bcba1e24396d162d516
Reviewed-on: https://chromium-review.googlesource.com/555670
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46342}
This is a reland of 72b88fdab8
Original change's description:
> [runtime] Make all built-in functions strict.
>
> According to ES#sec-built-in-function-objects all built-in functions
> must be strict.
>
> This is a preliminary CL before changing the way we define built-in
> functions in native JS files.
>
> Bug: v8:6529, v8:6459
> Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
> Reviewed-on: https://chromium-review.googlesource.com/546215
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46237}
Bug: v8:6529, v8:6459
Change-Id: Ic0eb3d7925ed63dd716c4a114601415f92627ca5
Reviewed-on: https://chromium-review.googlesource.com/550156
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46262}
This reverts commit 72b88fdab8.
Reason for revert: Changes a layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16595
Original change's description:
> [runtime] Make all built-in functions strict.
>
> According to ES#sec-built-in-function-objects all built-in functions
> must be strict.
>
> This is a preliminary CL before changing the way we define built-in
> functions in native JS files.
>
> Bug: v8:6459
> Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
> Reviewed-on: https://chromium-review.googlesource.com/546215
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46237}
TBR=adamk@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: Ic458b478b2dd23aae7ea2a51aa6052c1f5931c56
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6459
Reviewed-on: https://chromium-review.googlesource.com/549322
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46242}
According to ES#sec-built-in-function-objects all built-in functions
must be strict.
This is a preliminary CL before changing the way we define built-in
functions in native JS files.
Bug: v8:6459
Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
Reviewed-on: https://chromium-review.googlesource.com/546215
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46237}
The implication was actually in the wrong direction: If there is no
memory start address, then the size must be 0.
If the size is 0 though, we might allocate nevertheless to have guard
pages around the accessible memory.
R=ahaas@chromium.org
BUG=chromium:736584
Change-Id: I297dece658d5eaf69c58ecb109ff21d3ca0b8a8d
Reviewed-on: https://chromium-review.googlesource.com/548635
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46221}
This removes the --turbo flag and solely relies on the filter pattern
provided via --turbo-filter when deciding whether to use TurboFan. Note
that disabling optimization wholesale can still be done with --no-opt,
which should be used in favor of --no-turbo everywhere.
Also note that this contains semantic changes to the TurboFan activation
criteria. We respect the filter pattern more stringently and no longer
activate TurboFan just because the source contains patterns forcing use
of Ignition via {AstNumberingVisitor::DisableFullCodegenAndCrankshaft}.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0c855f6a62350eb62283a3431c8cc1baa750950e
Reviewed-on: https://chromium-review.googlesource.com/528121
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46167}
This CL leverages and extends the deopt-to-stub mechanisms previously
introduced to support deopting from CSA-built builtins (e.g. Array.prototype.forEach).
BUG=v8:6373
LOG=N
Review-Url: https://codereview.chromium.org/2890363002
Cr-Commit-Position: refs/heads/master@{#46144}
transition, check to see if we have already done this transition.
BUG=v8:6450
Review-Url: https://codereview.chromium.org/2915863004
Cr-Commit-Position: refs/heads/master@{#46129}
In edge cases such as the following, sloppy-mode block-scoped function
hoisting is expected to occur:
eval(`
with({a: 1}) {
function a() {}
}
`)
In this case, there should be the equivalent of a var declaration
outside of the eval, which gets set to the value of the local function
a when the body of the with is executed.
Previously, the way that var declarations are hoisted out of eval
meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
assignment. However, such a lookup mode meant that the object in the
with scope received the assignment!
This patch fixes that error by marking the assignments produced by
the sloppy mode block scoped function hoisting desugaring so as to
generate a different runtime call which skips with scopes.
Bug: chromium:720247, v8:5135
Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
Reviewed-on: https://chromium-review.googlesource.com/529230
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46116}
If one wasm instance imports an exported function of another instance,
we unwrap the js-to-wasm wrapper of the export and use the underlying
code object directly. However, the code object does not keep the wasm
instance alive. It is only connected via a WeakCell.
With this CL, we explicitly store a FixedArray of all wasm instances
from which we imported functions to keep them alive at least as long as
the instance which imports the code.
R=mtrofin@chromium.org, ahaas@chromium.org
BUG=chromium:734345
Change-Id: I8dcfc9a4ea2d791a62d8cb7255039e481c50bdfd
Reviewed-on: https://chromium-review.googlesource.com/539738
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46062}
This makes sure that the coercion of global import values to numbers
remains non-observable to JavaScript. It allows instantiation failures
to fall back to JavaScript proper without accidentally causing some
side-effect to happen twice. Also coercions might invalidate previous
checks done during linking or throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6431
BUG=v8:6431
Change-Id: Ibe2f7a336bc0fb25532d526746ecc802e04bbd5c
Reviewed-on: https://chromium-review.googlesource.com/512544
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46051}
The constructor of WireBytesRef checks that offset+length is still in
the uint32_t range. This CL avoids triggering this check on illegally
size strings.
R=ahaas@chromium.org
BUG=chromium:734246
Change-Id: Iab5c7013aa3e0ac5060bc4733e712a1652679b1a
Reviewed-on: https://chromium-review.googlesource.com/539402
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46050}
If we pass in thin-string into a keyed load, the underlying internalized string is used to find the handler. However, the thin string itself was used to interpret the handler. Since the thin string itself isn't unique, this caused existing properties on the prototype chain to not be found in case of dictionary-mode prototypes.
Bug: chromium:731193
Change-Id: Ic98d3789ecf9175e17d9c898ab13231aad59efcc
Reviewed-on: https://chromium-review.googlesource.com/539596
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46005}
Large allocations would fail due to the flag not being set.
Bug: chromium:732836
Change-Id: I31686e382386a2d08582c86b29dc8f89841040d1
Reviewed-on: https://chromium-review.googlesource.com/535563
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45999}
Storing the boilerplate on the first run leads to memory ovehead for code
that is run only once. Hence we directly return the creating literal on the
first run and only start creating copies from the second run on.
Bug: v8:6211
Change-Id: I69b96d124a5b594b991fdbcc76dbf935d973ffad
Reviewed-on: https://chromium-review.googlesource.com/530688
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45975}
For unknown Argument object Maps we have to expect that constants fields
are kept on the Map.
Bug: chromium:729597
Change-Id: I110f77455ce434a431c8de27d021b1a5deb86f30
Reviewed-on: https://chromium-review.googlesource.com/532900
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45935}
TracingCpuProfiler test updates the current plaform while
concurrent marking is running.
This patch also disables stress-incremental-marking for
mjsunit/regress-430201.
BUG=chromium:694255
Change-Id: I85ff538c47bce0300cde3204989ef3f9512b805f
Reviewed-on: https://chromium-review.googlesource.com/533873
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45921}
The function that generated a pre-shifted immediate didn't account for the
instruction with post-shift being unencodable. Fix this by passing
information about the target instruction, and use it to limit the application
of pre-shift.
BUG=chromium:725858
Change-Id: Ia0f70b2ea057975d90162aa6889f15b553acd321
Review-Url: https://codereview.chromium.org/2922173004
Cr-Commit-Position: refs/heads/master@{#45911}
This adds missing support for in-object properties within objects having
the {JSGeneratorObject} type to materialization during deoptimization.
For corner-cases where the implicit generator object is statically known
not to escape, object layout might still be arbitrarily complex.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169,v8:6481
Change-Id: I32f373913d60af64981dc4ed66873cc8a1dbe872
Reviewed-on: https://chromium-review.googlesource.com/530230
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45870}
This adds support for materializing objects of {JSGeneratorObject} type
during deoptimization. Cases where soft-deopts remove any escaping use
of the implicit generator object can cause it to be escape analyzed.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169
Change-Id: I2ec10b2a509a4f37a456a8ca2fd74b8de2fb55be
Reviewed-on: https://chromium-review.googlesource.com/530847
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45849}
Don't treat new prototypes differently depending on how they become a
prototype. This is work towards always keeping prototypes in slow-mode.
Bug: v8:6471
Change-Id: I62de1018e21d91fda3a5da044615f32c718910b1
Reviewed-on: https://chromium-review.googlesource.com/526596
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45781}
When the slow path for Array.prototype.indexOf calls a Proxy's "has"
trap, it must check afterwards whether an exception was thrown.
BUG=chromium:728813
Change-Id: I998bba6ddcd65adfed2eefb63b3285da60d2a43c
Reviewed-on: https://chromium-review.googlesource.com/527173
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45759}
This cl: https://chromium-review.googlesource.com/509613 changed
CheckNotTaggedHole to not produce any value output. This would mean that
in some cases, we could leak hole on value edges. This violates the
assumption that we cannot see a hole on several operators. Fixing this
back to the original state.
Bug: chromium:730254
Change-Id: I3512930e88dbe15e9d9b4b0d276868f354cc2ae2
Reviewed-on: https://chromium-review.googlesource.com/527033
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45757}
It's possible to build circular objects through the reviver function in
JSON.parse. Recursion needs to check for stack overflows and throw as
needed.
BUG=chromium:729671
Change-Id: I52ccd9ed9fea5829810879f8dd8207043fa6d910
Reviewed-on: https://chromium-review.googlesource.com/525812
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45752}
The inlining of Function.prototype.bind can lead to escape analyzed
bound functions, which weren't handled by the Deoptimizer previously.
BUG=chromium:729573
R=jarin@chromium.org,cbruni@chromium.org
Review-Url: https://codereview.chromium.org/2931483003
Cr-Commit-Position: refs/heads/master@{#45751}
The regression is already fixed. This just adds a regression test to
ensure it will never be reintroduced.
R=ahaas@chromium.org
BUG=chromium:729991
Change-Id: I5cf960cc756cbb7723041bc06a78d6a14c66e241
Reviewed-on: https://chromium-review.googlesource.com/525538
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45739}
When optimizing stores to data properties in literals, we need to first
migrate deprecated maps before we lookup the property access infos for
those.
BUG=chromium:724608
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2930433003
Cr-Commit-Position: refs/heads/master@{#45727}
TBR=ishell@chromium.org
Bug: v8:6457
Change-Id: I09d7d6ff8460688b7ddf25f733aea73a620db953
Reviewed-on: https://chromium-review.googlesource.com/523037
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45699}
Execution tests regress-336820 and regress-678917 finished with error
messages "allocation failure GC in old space requested" and "fatal
javascript OOM in CALL_AND_RETRY_LAST". For successful execution,
parameter max_old_space_size must be increased and this is done inside
tests.
TEST=mjsunit/regress/regress-336820,
mjsunit/regress/regress-678917
BUG=
Review-Url: https://codereview.chromium.org/2907363003
Cr-Original-Commit-Position: refs/heads/master@{#45672}
Committed: 1550c86909
Review-Url: https://codereview.chromium.org/2907363003
Cr-Commit-Position: refs/heads/master@{#45681}
Execution tests regress-336820 and regress-678917 finished with error
messages "allocation failure GC in old space requested" and "fatal
javascript OOM in CALL_AND_RETRY_LAST". For successful execution,
parameter max_old_space_size must be increased and this is done inside
tests.
TEST=mjsunit/regress/regress-336820,
mjsunit/regress/regress-678917
BUG=
Review-Url: https://codereview.chromium.org/2907363003
Cr-Commit-Position: refs/heads/master@{#45672}
Currently x instanceof Map/Set checks cannot take the fast path, since
the Map/Set constructor has dictionary properties. To avoid that, just
forcibly migrate the Map/Set constructor to fast properties again once
it's fully setup in the bootstrapper.
Bug: v8:5717, v8:5902
Change-Id: I23dfd00456c9206a0ca5af71dfbc9236982936fc
Reviewed-on: https://chromium-review.googlesource.com/520578
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45663}
Causes crashes on canary if there is a GC and the value makes it onto
the stack.
Bug: chromium:727662
Change-Id: I44fa8cf8a83b43d64418896c0a1f5518401b454f
Reviewed-on: https://chromium-review.googlesource.com/519302
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45623}
It's extremely difficult to get right: there have been several bugs
related to this feature, especially when combined with
non-simple parameter lists in arrow functions.
BUG=chromium:727218
Change-Id: I97dfbc57a7650199964c5fe99de69143c8e537c2
Reviewed-on: https://chromium-review.googlesource.com/518145
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45603}
This may happen in KeyedStoreIC when the last store via setter deprecates the receiver map.
Bug: chromium:723366
Change-Id: Iff19e50c3761584401340d276ab4eead111883c3
Reviewed-on: https://chromium-review.googlesource.com/517952
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45592}
This time for the current memory size. This call also used to use the
context object stored in the instance, hence it required the instance
to be set. This is no longer the case, so the DCHECKs can just be
removed.
R=ahaas@chromium.org
BUG=chromium:727222
Change-Id: I72a7e3e80c3beb15ecad00c5be068e803456797e
Reviewed-on: https://chromium-review.googlesource.com/517947
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45587}
This widens the range of value output counts to 32 bit on the {Operator}
class. Note that the limit imposed by the parser is 65535 parameters for
each function, but the {Start} node has additional value outputs.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-724153
BUG=chromium:724153
Change-Id: I21b5d947cc2305b255ddbbff6ec1dfa5c02784c7
Reviewed-on: https://chromium-review.googlesource.com/517489
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45573}
For lazy compilation, we encode information about table exports in the
deoptimization data. This information is rebuilt on each instantiation,
so we need to reset it when reusing code objects from another instance.
R=ahaas@chromium.org
BUG=chromium:727219
Change-Id: I90557ef06e692d0a8323223cac26679efcfa408b
Reviewed-on: https://chromium-review.googlesource.com/517945
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45559}
... to make AsyncFunction subclassing work.
Bug: chromium:725537
Change-Id: I7edf4891e14e01567046e7536b3aa93877111448
Reviewed-on: https://chromium-review.googlesource.com/517087
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45544}
Add a protector cell for string bounds checks that is being used to
protect speculative bounds for String.prototype.charCodeAt and
String.prototype.charAt in TurboFan (and Crankshaft). This way we don't
have the diamond in optimized code, which stands in the way of other
optimizations for charCodeAt that are currently being worked on by
petermarshall@.
BUG=v8:6391
TBR=mlippautz@chromium.orgR=petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2905623003
Cr-Commit-Position: refs/heads/master@{#45514}
This makes sure that property lookups on the provided imports object are
non-observable to JavaScript. It allows instantiation failures to fall
back to JavaScript proper without accidentally calling accessors twice.
Also accessors might invalidate previous checks done during linking or
throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-719384
BUG=chromium:719384
Change-Id: I3db2672d2a496110f705d02b82878e70cd5d701f
Reviewed-on: https://chromium-review.googlesource.com/509552
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45481}
Validation normally happens while generating the turbofan graph of a
wasm function. For lazy compilation (behind the flag
--wasm-lazy-compilation), we skip this graph generation step during
module generation. Thus we need to validate explicitely.
R=ahaas@chromium.org
BUG=chromium:724851
Change-Id: Ic70887c0d823460a272d0bb636dc98b2b7a7e55e
Reviewed-on: https://chromium-review.googlesource.com/509574
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45478}
If the maximum number of memory pages is raised using
--wasm-max-mem-pages, we might allocate more than kMaxInt bytes for
wasm memory. The byte length is stored as int in JSArrayBuffer, hence
this can lead to failures.
Thus, we now additially check against kMaxInt, and fail instantiation
if this check fails.
Drive-by: Add/fix more bounds checks.
R=ahaas@chromium.org
BUG=chromium:724846
Change-Id: Id8e1a1e13e15f4aa355ab9414b4b950510e5e88a
Reviewed-on: https://chromium-review.googlesource.com/509255
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45465}
