Skip to content

V
V8
Switch branch/tag
  1. 30 Apr, 2018 2 commits
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored 
      The idea is to mark all the branches and loads participating in array
bounds checks, and let them contribute-to/use the poisoning register.
In the code, the marks for array indexing operations now contain
"Critical" in their name. By default (--untrusted-code-mitigations),
we only instrument the "critical" operations with poisoning.

With that in place, we also remove the array masking approach based
on arithmetic.

Since we do not propagate the poison through function calls,
we introduce a node for poisoning an index that is passed through
function call - the typical example is the bounds-checked index
that is passed to the CharCodeAt builtin.

Most of the code in this CL is threads through the three levels of
protection (safe, critical, unsafe) for loads, branches and flags.

Bug: chromium:798964

Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
Reviewed-on: https://chromium-review.googlesource.com/995413
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
    • Jaroslav Sevcik's avatar
      [turbofan] Remove the hacky Type::operator-> overload · ba616de1
      Jaroslav Sevcik authored 
      This removes Type::operator-> which was used to split the change that
removed undefined misuse of Type* to represent integers.

Bug: v8:3770
Change-Id: I9a5bce5ccdc75461a7b939b4070cb58fe6040d99
Reviewed-on: https://chromium-review.googlesource.com/1033736Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52878}
      ba616de1
  3. 28 Apr, 2018 1 commit
  5. 26 Apr, 2018 1 commit
  7. 25 Apr, 2018 1 commit
  9. 24 Apr, 2018 1 commit
  11. 23 Apr, 2018 1 commit
  13. 19 Apr, 2018 1 commit
  15. 04 Apr, 2018 1 commit
  17. 27 Mar, 2018 2 commits
  19. 23 Mar, 2018 2 commits
  21. 21 Mar, 2018 1 commit
  23. 20 Mar, 2018 1 commit
  25. 19 Mar, 2018 1 commit
  27. 16 Mar, 2018 3 commits
  29. 15 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Teach TurboFan about the TypedArray constructor. · 0875778f
      Benedikt Meurer authored 
      This introduces a new JSCreateTypedArray operator, backed by a dedicated
CreateTypedArray builtin, and adds support to lowering new TypedArray
calls to this operator. This way we avoid the overhead of going through
the generic construct stub machinery for hot code. This not only
recovers the performance regression on the typed array constructor
benchmarks, but even improves slightly beyond what we had in 6.6.

We might in the future try to fully inline the TypedArray constructor
into optimized code for certain cases.

Bug: chromium:820726, v8:7503, v8:7518
Change-Id: Ied465924d5695db576d533792f1db68456b9b5ea
Reviewed-on: https://chromium-review.googlesource.com/959010
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51973}
      0875778f
  31. 12 Mar, 2018 1 commit
  33. 07 Mar, 2018 1 commit
  35. 05 Mar, 2018 2 commits
    • Sigurd Schneider's avatar
      [turbofan] Fix undefined behavior in accessing operator parameters · efed5562
      Sigurd Schneider authored 
      OpParameter<int32_t> was still used for an operator after the operators
parameter changed from int32_t to a struct. Coincidentally, the first
field of the struct holds the value previously stored in that int32_t,
so correctness tests did not catch this.

Bug: chromium:818611, v8:7517
Change-Id: Ie46f084f7fa8117cd3493fc5ceafac11553dc55e
Reviewed-on: https://chromium-review.googlesource.com/948546
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51728}
      efed5562
    • Benedikt Meurer's avatar
      [es2015] Refactor the JSArrayIterator. · 06ee127b
      Benedikt Meurer authored 
      This changes the JSArrayIterator to always have only a single instance
type, instead of the zoo of instance types that we had before, and
which became less useful with the specification update to when "next"
is loaded from the iterator now. This greatly simplifies the baseline
implementation of the array iterator, which now only looks at the
iterated object during %ArrayIteratorPrototype%.next invocations.

In TurboFan we introduce a new JSCreateArrayIterator operator, that
holds the IterationKind and get's the iterated object as input. When
optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
check whether the receiver is a JSCreateArrayIterator, and if so,
we try to infer maps for the iterated object from there. If we find
any, we speculatively assume that these won't have changed during
iteration (as we did before with the previous approach), and generate
fast code for both JSArray and JSTypedArray iteration.

Drive-by-fix: Drop the fast_array_iteration protector, it's not
necessary anymore since we have the deoptimization guard bit in
the JSCallReducer now.

This addresses the performance cliff noticed in webpack 4. The minimal
repro on the tracking bug goes from

  console.timeEnd: mono, 124.773000
  console.timeEnd: poly, 670.353000

to

  console.timeEnd: mono, 118.709000
  console.timeEnd: poly, 141.393000

so that's a 4.7x improvement.

Also make presubmit happy by adding the missing #undef's.

Bug: v8:7510, v7:7514
Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
Reviewed-on: https://chromium-review.googlesource.com/946098Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51725}
      06ee127b
  37. 02 Mar, 2018 2 commits
  39. 23 Feb, 2018 5 commits
  41. 20 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize promise resolution. · be6d1292
      Benedikt Meurer authored 
      This CL introduces new operators JSFulfillPromise and JSPromiseResolve,
corresponding to the specification operations with the same name, and
uses that to lower calls to Promise.resolve() builtin to JSPromiseResolve.

We also optimize JSPromiseResolve and JSResolvePromise further based on
information found about the value/resolution in the graph. This applies
to both Promise.resolve() builtin calls and implicit resolve operations
in async functions and async generators.

On a very simple microbenchmark like

  console.time('resolve');
  for (let i = 0; i < 1e8; ++i) Promise.resolve({i});
  console.timeEnd('resolve');

this CL reduces the execution time from around 3049ms to around 947ms,
which is a pretty significant 3x improvement. On the wikipedia benchmark
we observe an improvement around 2% with this CL.

Bug: v8:7253
Change-Id: Ic69086cdc1b724f35dbe83305795539c562ab817
Reviewed-on: https://chromium-review.googlesource.com/913488Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51387}
      be6d1292
  43. 16 Feb, 2018 1 commit
  45. 15 Feb, 2018 1 commit
  47. 14 Feb, 2018 1 commit
  49. 13 Feb, 2018 3 commits
    • Camillo Bruni's avatar
      [errors] Use FATAL macro where possible · 52b3b491
      Camillo Bruni authored 
      FATAL(...) avoid creating literal strings for line number in release
mode.

Bug: v8:7310
Change-Id: I6a3e329adce36b0efcc240068f6a241d1cca4b6f
Reviewed-on: https://chromium-review.googlesource.com/915066Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51277}
      52b3b491
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, x64) · 8f489e73
      Mike Stanton authored 
      This introduces masking of loads with speculation bit during code generation.
At the moment, this is done only for x64 optimized code, under the
--branch-load-poisoning flag.

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: Ie51fdbde578fc289dff029794f3cfe8eaf33e1ef
Reviewed-on: https://chromium-review.googlesource.com/901625
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51272}
      8f489e73
    • Benedikt Meurer's avatar
      [builtins] Refactor the promise resolution and rejection logic. · c0412961
      Benedikt Meurer authored 
      This introduces dedicated builtins

  - FulfillPromise,
  - RejectPromise, and
  - ResolvePromise,

which perform the corresponding operations from the language
specification, and removes the redundant entry points and the
excessive inlining of these operations into other builtins. We
also add the same logic on the C++ side, so that we don't need
to go into JavaScript land when resolving/rejecting from the
API.

The C++ side has a complete implementation, including full support
for the debugger and the current PromiseHook machinery. This is to
avoid constantly crossing the boundary for those cases, and to also
simplify the CSA side (and soon the TurboFan side), where we only
do the fast-path and bail out to the runtime for the general handling.

On top of this we introduce %_RejectPromise and %_ResolvePromise,
which are entry points used by the bytecode and parser desugarings
for async functions, and also used by the V8 Extras API. Thanks to
this we can uniformly optimize these in TurboFan, where we have
corresponding operators JSRejectPromise and JSResolvePromise, which
currently just call into the builtins, but middle-term can be further
optimized, i.e. to skip the "then" lookup for JSResolvePromise when
we know something about the resolution.

In TurboFan we can also already inline the default PromiseCapability
[[Reject]] and [[Resolve]] functions, although this is not as effective
as it can be right now, until we have inlining support for the Promise
constructor (being worked on by petermarshall@ right now) and/or SFI
based CALL_IC feedback.

Overall this change is meant as a refactoring without significant
performance impact anywhere; it seems to improve performance of
simple async functions a bit, but otherwise is neutral.

Bug: v8:7253
Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
      c0412961
  51. 12 Feb, 2018 1 commit
    • Ross McIlroy's avatar
      [Ignition] [TurboFan] Generate speculation poison in code generator. · a021b6c4
      Ross McIlroy authored 
      Moves generation of speculation poison to be based on the PC target vs the
actual PC being executed. The speculation poison is generated in the prologue
of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
The result is stored in a known register, which can then be read using the
SpeculationPoison machine node.

Currently we need to ensure the SpeculationPoison node is scheduled right after
the code prologue so that the poison register doesn't get clobbered. This is
currently not verified, however it's only use is in RawMachineAssembler where
it is manually scheduled early.

The Ignition bytecode handlers are updated to use this speculation poison
rather than one generated by comparing the target bytecode.

BUG=chromium:798964

Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
Reviewed-on: https://chromium-review.googlesource.com/893160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51229}
      a021b6c4
  53. 08 Feb, 2018 1 commit
    • Adam Klein's avatar
      Revert "[builtins] Mega-revert to address the Dev blocker in crbug.com/808911." · 3916401e
      Adam Klein authored 
      This reverts commit 14108f4c.

Reason for revert: Not the culprit for Canary microtask crashes

Original change's description:
> [builtins] Mega-revert to address the Dev blocker in crbug.com/808911.
> 
> - Revert "[builtins] Save one word in contexts for Promise.all."
>   This reverts commit 7632da06.
> - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
>   This reverts commit d4f072ce.
> - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
>   This reverts commit 6703dacd.
> - Revert "[debugger] Properly deal with settled promises in catch prediction."
>   This reverts commit 40dd0658.
> - Revert "[builtins] Widen the fast-path for Promise builtins."
>   This reverts commit db0556b7.
> - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
>   This reverts commit a582199c.
> - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
>   This reverts commit 6bf88852.
> - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
>   This reverts commit 313b490d.
> - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
>   This reverts commit f7bd6a2f.
> - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
>   This reverts commit b23b098f.
> - Revert "[promise] Remove incorrect fast path"
>   This reverts commit 0f6eafe8.
> - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
>   This reverts commit 8a677a28.
> - Revert "[builtins] Refactor promises to reduce GC overhead."
>   This reverts commit 8e7737cb.
> 
> Tbr: hpayer@chromium.org
> Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
> Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/906991
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51158}

Change-Id: I09d958cbebd635a325809072a290f2f53df8c5d4
Tbr: adamk@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/908988Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51181}
      3916401e