Change-Id: Idbee9b7b8077a9fd2ffa4a2a010ae7d44b98e31e
Reviewed-on: https://chromium-review.googlesource.com/924198
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51378}
Factor out IterableToList into a helper stub to save space. There are
two callers now, TypedArrayFrom and ConstructByIterable, and it is
~2.5kb so we save space by doing this.
Increase test coverage to cover more of the branching in CSA.
This is doesn't follow the control flow in the spec exactly - see the
big code comment for an explanation.
Change-Id: Ief39e93c4202cb7bf0e28a39dc6aa81b8b9c59d2
Reviewed-on: https://chromium-review.googlesource.com/908755
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51377}
The result of an f64 binop was marked as f32 on Liftoffs value stack.
This lead to errors and is fixed in this CL.
I plan to clean up all binop implementions in a follow-up CL.
R=titzer@chromium.org
Bug: chromium:812005, v8:6600
Change-Id: I5bcd5c2e7d2b6170ef60f5e83cf2876b3475c38a
Reviewed-on: https://chromium-review.googlesource.com/924025
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51375}
This introduces masking of loads with speculation bit during code generation.
At the moment, this is done only under the
--branch-load-poisoning flag, and this CL enlarges the set of supported
platforms from {x64} to {x64, arm}.
Overview of changes:
- new register configuration configuration with one register reserved for
the speculation poison/mask (kSpeculationPoisonRegister).
- in codegen, we introduce an update to the poison register at the starts
of all successors of branches (and deopts) that are marked as safety
branches (deopts).
- in memory optimizer, we lower all field and element loads to PoisonedLoads.
- poisoned loads are then masked in codegen with the poison register.
* only integer loads are masked at the moment.
Bug: chromium:798964
Change-Id: I37f5531fd18a96038ea8b059641e3dfc852c2d34
Reviewed-on: https://chromium-review.googlesource.com/913354
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51374}
Previously, eval caching was only disabled if the root eval body code
contained a tagged template. Per discussion on
https://github.com/tc39/ecma262/pull/890, this is incorrect.
This change tracks if eval caching is allowed during parsing, and
uses this information to decide to insert
new entries into the cache, or not.
This change also removes the TemplateObject feedback kind, as it's no
longer needed (behaves the same as Literal feedback).
BUG=v8:3230, v8:2891
R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
rmcilroy@chromium.org
Change-Id: Ib75abe9159baf4d8ad10f8de99d2152714bd0094
Reviewed-on: https://chromium-review.googlesource.com/916945
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51373}
Reland reason : not the culprit.
This will let us identify in traces whether unwinding after receiving
the preemption event is slower than desired and should be optimized.
Adding it to pausing while working on removing it in
https://chromium-review.googlesource.com/c/v8/v8/+/922103
will allow gathering traces that highlight the issue.
R=ulan@chromium.org
Bug: chromium:812178
Change-Id: I0dc0f6754980157674968ba4a868f12c779e69bc
Reviewed-on: https://chromium-review.googlesource.com/923989
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51372}
There is a debug check to check that an embedded code object is patched
correctly. This check only makes sense if the code object was indeed
pushed to the stack, otherwise we are checking the type marker.
This CL fixes this check and adds a line of documentation.
R=mstarzinger@chromium.org
Change-Id: I5bc1454232cdbf2e9fef6eb41f7c7a20f31a5250
Reviewed-on: https://chromium-review.googlesource.com/924154
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51370}
This implements the br_table instruction in LiftoffCompiler by emitting
a binary search tree.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I89c11501dd3a41556d2fab68af1afbe8c4855d36
Reviewed-on: https://chromium-review.googlesource.com/921641
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51368}
Set the VMA address for jitted code to the address of the code. This
should be the correct value, as the code got loaded to that address at
runtime.
Change-Id: I6ce9181d940dd4568d93a92e98d206f3c6546ebc
Reviewed-on: https://chromium-review.googlesource.com/915923
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51367}
Since these instructions will be used in liftoff as well as they
are used in code generator, they are transfered to macro assembler.
Change-Id: I48e60ccc7586252374bc66b7b72bbe23c2d0c0a6
Reviewed-on: https://chromium-review.googlesource.com/924194
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Cr-Commit-Position: refs/heads/master@{#51366}
This reverts commit 4b49f84434.
Reason for revert: Several GC failures, e.g. https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/23236, https://build.chromium.org/p/client.v8/builders/V8%20Mac/builds/18390
Original change's description:
> Add a trace event when pausing/preempting concurrent marking.
>
> This will let us identify in traces whether unwinding after receiving
> the preemption event is slower than desired and should be optimized.
>
> Adding it to pausing while working on removing it in
> https://chromium-review.googlesource.com/c/v8/v8/+/922103
> will allow gathering traces that highlight the issue.
>
> R=mlippautz@chromium.org
>
> Bug: chromium:812178
> Change-Id: I0555c6825e0792769c9ae2d748d7cc35df4f6fed
> Reviewed-on: https://chromium-review.googlesource.com/924122
> Commit-Queue: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51354}
TBR=gab@chromium.org,mlippautz@chromium.org
Change-Id: I37a82e488de51d5ae4d7ed795b82ea9649c4a5f9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:812178
Reviewed-on: https://chromium-review.googlesource.com/924426
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51364}
This extends the previously introduced logic for implementing await
without having to allocate the throwaway promise and the additional
closures and context, to also cover await and yield inside of async
generators.
Bug: v8:7253
Change-Id: I011583a7714bbd148c54e5f204e2076630008db0
Reviewed-on: https://chromium-review.googlesource.com/924003
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51361}
This adds PersistentBase::AnnotateStrongRetainer(const char*) function.
The annotation is used by the heap snapshot generator to show the edges
from the (Global handles) root to the global handles.
Bug: chromium:811842
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1a9e3e53a53aeaf2b590709fab8dd4ecf7e8f252
Reviewed-on: https://chromium-review.googlesource.com/916788
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51358}
This will let us identify in traces whether unwinding after receiving
the preemption event is slower than desired and should be optimized.
Adding it to pausing while working on removing it in
https://chromium-review.googlesource.com/c/v8/v8/+/922103
will allow gathering traces that highlight the issue.
R=mlippautz@chromium.org
Bug: chromium:812178
Change-Id: I0555c6825e0792769c9ae2d748d7cc35df4f6fed
Reviewed-on: https://chromium-review.googlesource.com/924122
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51354}
This is a reland of dda0419ecd.
Originally reviewed-on: https://chromium-review.googlesource.com/914513
and landed as refs/heads/master@{#51342}.
Bug: v8:6791
Change-Id: I3b3a069da7a0e64c38a81b3110dc5ece4887cb19
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/924665
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51352}
This replaces three passes over the roots with a single pass.
This also removes root synchronization logic.
The GC subroot index is computed from the |root| parameter of the visit
method. The new |description| parameter is used as an edge name.
Bug: chromium:811842
Change-Id: I03a9215d56b54b3eb5f7bc8b32d5b22ad091c68b
Reviewed-on: https://chromium-review.googlesource.com/916781
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51350}
This was extracted from https://chromium-review.googlesource.com/c/v8/v8/+/924073/7
in an attempt to isolate hard-to-diagnose bots-only failures there.
Bug: chromium:812178
Change-Id: I980b25ec7d775b74ade75e9166806740b93eea8e
Reviewed-on: https://chromium-review.googlesource.com/924026
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51349}
This is an attempt to isolate what's causing the hard-to-diagnose bots only
failures with that CL.
Bug: chromium:812178
Change-Id: I50ffe8953bebbbc6b5a5e2f689718662a537acb4
Reviewed-on: https://chromium-review.googlesource.com/924864
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51348}
- Replaces calls to Allocator Reserve, Free, and SetPermissions
with equivalent page allocator calls (allocation.h).
- Un-implements these methods to catch usage, in preparation for
removing these.
Bug: chromium:799573
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id233b7a9cfc8e332c64e514f6359e8b670c2d75e
Reviewed-on: https://chromium-review.googlesource.com/911883
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51340}
We already cleanup these scripts on frontend side. It is crucial to
cleanup them on backend side as well, since some web applications use
following logic: get some data from network, add this data to buffer,
try to parse buffer using JSON.parse. On each unsuccessfull JSON.parse
we get another scriptFailedToParse event.
Frontend logic of discarding scripts: https://goo.gl/FDtaWK
Some idea of smarter logic here: track what script ids are reported
using protocol and cleanup only script ids which reported not only as
part of scriptFailedToParse event.
R=alph@chromium.org
Bug: chromium:810812
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifd67764c232e4abc7dc6e8e69a651bf9ac0e381b
Reviewed-on: https://chromium-review.googlesource.com/919834
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51337}
This will enable some fuzzers to alter the thread-pool size.
Bug: v8:7455
Change-Id: Ic9c9600cdb3dc50e860dbda8432a23bb20f1dd44
Reviewed-on: https://chromium-review.googlesource.com/924273
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51335}
The ES2017 specification contains a so-called "throwaway" promise that
is used to specify the behavior of await in terms of PerformPromiseThen,
but it's actually not necessary and never exposed to user code. In
addition to that, hooking up the promise in await required a context (to
refer to the generator object) and two closures for the reject/fulfill
handling, which would resume the generator corresponding to the async
function. That meant, we had to allocate 4 additional objects for every
await.
Instead of using a JSPromise plus the callbacks, this CL adds logic to
allow PromiseReaction and PromiseReactionJobTask to carry arbitrary
payloads and Code handlers. We use this for await to avoid the
additional 4 objects mentioned above, and instead just have simple Code
handlers that resume the generator (for the async function), either by
throwing (in case of a rejection) or by resuming normally (in case of
fulfillment).
For this to work properly the JSGeneratorObject has to have a link to
the outer promise returned by the async function, so that the catch
prediction can still figure out what to do in case of promise rejection.
This is done by adding a new generator_outer_promise_symbol when the
debugger is active, which refers from the generator to the outer
promise.
With this change the doxbee-async-es2017-native test goes from around
100.54ms to around 82.45ms, which corresponds to a ~18% reduction in
execution time.
Bug: v8:7253
Change-Id: Iae25b3300bac351c3417be5ae687eff469b0e61f
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/924069
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51334}
Add TurboFan inlining support for the following V8 Extras:
- v8.createPromise
- v8.rejectPromise
- v8.resolvePromise
These are used by the streams implementation in Chrome currently, and
were previously not inlined into TurboFan, although TurboFan already
had all the necessary functionality (namely the JSCreatePromise,
JSRejectPromise and JSResolvePromise operators). We might eventually
want to use these functions in Node core as well (at least short-term
for Node 10), to replace the C++ internal API functions with the same
name that are currently being used by parts of Node core.
For this to work, the rejectPromise and resolvePromise builtins had
to be moved back to CSA, as for JavaScript builtins we still have the
policy that the optimizing compiler must not inline them. But that's
straight-forward since the CSA has all the necessary functionality
available anyways.
Bug: v8:7253
Change-Id: I39ab015c379956cd58ace866e17f8ec23b2257b2
Reviewed-on: https://chromium-review.googlesource.com/924146
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51332}
This flag is the WebAssembly native heap equivalent to
FLAG_write_protect_code_memory.
R=mstarzinger@chromium.org
Bug: v8:7454
Change-Id: Id4f671af2e8676d08599c8c30ce03b00e9d33780
Reviewed-on: https://chromium-review.googlesource.com/924071
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51330}
