Skip to content

V
V8
Switch branch/tag
  1. 12 Feb, 2021 8 commits
  3. 11 Feb, 2021 4 commits
  5. 10 Feb, 2021 4 commits
    • Daniel Clark's avatar
      Fix top-level await crash from synthetic module being evaluated twice · f033e2a1
      Daniel Clark authored 
      With top-level await, when Evaluate is performed on an already-evaluated
synthetic module, Module::InnerEvaluate returns undefined.  This breaks
top-level await's assumption that the returned value is always a
promise.

In order to make SyntheticModule's behavior consistent with
SourceTextModule, the top_level_capability field is moved up to Module
and SyntheticModule::Evaluate places the promise returned from the
host's evaluation steps in that field.  Now SourceTextModule and
SyntheticModule can share the same code to handle the case where the
module is either kErrored or kEvaluated, so the code for this
is moved up to Module.

Thus, SyntheticModule is now guaranteed to return the
promise from the evaluation steps even on subsequent Evaluate() calls.

Unfortunately Node hasn't yet updated their EvaluationStepsCallback
to return a Promise, so we can't yet assume that the returned value
is a Promise without breaking Node.  So, this change also adds a clause
to check for this condition and create a new resolved Promise if one
was not provided by the callback steps.  This could eventually be
removed once Node's callback steps are updated for top-level await.

Change-Id: I2d6ae918abfeba9e3a757838502d4df92946edaa
Bug: v8:11398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673794Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72629}
      f033e2a1
    • Michael Achenbach's avatar
      [test] Run tests on all Mac bots in the pool · 880f2fac
      Michael Achenbach authored 
      Dropping the gpu:none dimension broadens the choice of Mac bots from
so far only 8-core VMs to also include 4-core and 12-core Mac Minis.

This CL adjusts the shard configs to account for adding
4-core Mac Minis to the choice.

We also skip a test that's slow only on 4-core bots.

No-Try: true
Bug: chromium:1174040,v8:11418
Change-Id: Ic0be0db197341b7b8f88eb30aa284c38b0e69609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685164
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72623}
      880f2fac
    • Georg Neis's avatar
      Revert "[compiler] Directly read PropertyCells" · 87df0b7e
      Georg Neis authored 
      This reverts commit 42cd9eb7.

Reason for revert: Clusterfuzz issues, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=1176318

Original change's description:
> [compiler] Directly read PropertyCells
>
> Main changes:
>
> - Introduce a new broker data kind kBackgroundSerialized for objects
>   that can be serialized in the background (when direct reads are on).
>   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
>   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> - Make PropertyCell use that new kind.
> - Introduce a bottleneck in runtime code for changes to PropertyCells
>   and make sure that a certain protocol is followed that allows
>   concurrent reads from the background thread.
> - Improve interface of PropertyCell in various ways.
>
> Bug: v8:7790
> Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72586}

TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org

Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72619}
      87df0b7e
    • Shu-yu Guo's avatar
      Reland "[regexp] Ship RegExp match indices" · e8ad04c8
      Shu-yu Guo authored 
      This reverts commit 8b6fd147.

This adds --no-stress-flush-bytecode to the failing assertOptimized test as the flag changed the GC pattern and was deoptimizing code.

Original change's description:
> Revert "[regexp] Ship RegExp match indices"
>
> This reverts commit 72464122.
>
> Reason for revert:
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/32046
>
> Original change's description:
> > [regexp] Ship RegExp match indices
> >
> > I2S:
> > https://groups.google.com/a/chromium.org/g/blink-dev/c/RR_dw_ZXtT0/m/xtgu5jjyAQAJ
> >
> > Bug: v8:9548
> > Change-Id: I8ccf2f4c38f9b9204ae47162303f21d2d44498e8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682508
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Auto-Submit: Shu-yu Guo <syg@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#72571}
>
> TBR=jgruber@chromium.org,syg@chromium.org
>
> Change-Id: I1173389082928aa5c9895ca4fb360c7ab8ec073b
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:9548
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681943
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72576}

TBR=machenbach@chromium.org,jgruber@chromium.org,syg@chromium.org

# Not skipping CQ checks because this is a reland.

Bug: v8:9548
Change-Id: Ie18b16f347061602f35e3dea371c03d2ae136127
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686098
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72613}
      e8ad04c8
  7. 09 Feb, 2021 5 commits
    • Brice Dobry's avatar
      Add RISC-V backend · ffd9e82d
      Brice Dobry authored 
      This very large changeset adds support for RISC-V.

Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
      ffd9e82d
    • Shu-yu Guo's avatar
      Set is_awaiting on async generators after await's Promise machinery · 8efed0f9
      Shu-yu Guo authored 
      The is_awaiting bit on async generators distinguishes waiting on an
await. When the async generator resumes from an await, the is_awaiting
bit is cleared.

It is possible through overriding Promise#constructor that `await`
throws *after* setting is_awaiting. There is an implicit try-catch
around the body of the async generator such that, usually, caught
exceptions would clear the is_awaiting bit. However, the exception
thrown from a monkeypatched Promise#constructor can be caught by script,
and thus never clear the is_awaiting bit.

This CL sets the is_awaiting bit *after* `await` completes, with the
exception of the return resumption. It is not possible to have the
exception thrown by the await in the return resumption be caught by
script.

Bug: chromium:1171667
Change-Id: I0b615617a5c949f03350ab0f06c42920d43b5488
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659508Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72593}
      8efed0f9
    • Mythri A's avatar
      [turboprop] Don't consider stores to constant fields as mutable · b9a59e38
      Mythri A authored 
      Turboprop doesn't use optimizations based on field constness to reduce
the number of deoptimizations. While this is safe for loads, for stores
if a different value is stored to a const field we should update the
constness of the field. This is needed so we can safely deopt any other
code that is relying on the constness of the field. Currently, turboprop
doesn't do this. So for now treat stores to constant fields similar to
TurboFan. In future, we may consider adding code to update the field
constness if necessary to reduce the number of deoptimizations.


Bug: chromium:1172797, v8:9684
Change-Id: I1d660457cb5d647e1283a495040a7e452fe1ac7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673401
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72590}
      b9a59e38
    • Georg Neis's avatar
      [compiler] Directly read PropertyCells · 42cd9eb7
      Georg Neis authored 
      Main changes:

- Introduce a new broker data kind kBackgroundSerialized for objects
  that can be serialized in the background (when direct reads are on).
  (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
  in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
- Make PropertyCell use that new kind.
- Introduce a bottleneck in runtime code for changes to PropertyCells
  and make sure that a certain protocol is followed that allows
  concurrent reads from the background thread.
- Improve interface of PropertyCell in various ways.

Bug: v8:7790
Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72586}
      42cd9eb7
    • Ulan Degenbaev's avatar
      Make Map::instance_type accessors atomic · 4d07f3f2
      Ulan Degenbaev authored 
      This fixes a false positive TSAN report where an object transitions to
a new map in StoreIC. The scenario:
1) Object a transitions from map1 to a newly created map2 in runtime.
   The map is installed with a release-store.
2) Object b transitions from map1 to map2 in StoreIC in generated code
   that is not visible to TSAN.
3) Concurrent marker visits object b and loads it map with an acquire
   load.

Since TSAN does not see the store in step (2) it thinks that the map
loaded in (3) is freshly allocated and is not guarded by a release
store.

Bug: v8:11353
Change-Id: Ifcace9edff987761a4098d3fdfb98c6190f1ee1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682641Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72578}
      4d07f3f2
  9. 05 Feb, 2021 2 commits
    • Benedikt Meurer's avatar
      [stack-traces] Speed up method name inference. · 57062d6c
      Benedikt Meurer authored 
      In JSStackFrame::GetMethodName() we try to infer a useful method name to
show for the closure to which the stack frame belongs. This is done by
first considering the functions name, and checking if the receiver has a
property with that name and if that property's value is the closure. In
case the function doesn't have a name or the property's value is not the
closure itself, we fall back to a reverse lookup of the closure within
the object (and its prototypes).

This CL speeds up this logic by attacking two problems:

1. The reverse lookup was performed by first using the KeyAccumulator to
   extract the names of all enumerable properties, and afterwards using
   the LookupIterator on each name, and testing the resulting property
   value against the closure. This is fairly slow and creates a lot of
   temporary objects and handles. We now look into the descriptor arrays
   or dictionary backing stores of the objects directly instead, which
   is easily 2-10x faster.
2. For the common case of `o.foo = function() { ... }` the parser already
   places an "inferred name" of `o.foo` onto the SharedFunctionInfo,
   which we can use as a hint to infer the name of the function instead
   of immediately falling back to the expensive reverse lookup.

This repairs the regression reported in http://crbug.com/1069425 and
recovers most of the slowdown reported in http://crbug.com/1077657
(there's still some overhead left from the async stack trace tracking).

Fixed: chromium:1069425
Bug: chromium:1077657
Change-Id: I88d23ccad123906df70c5217e815493106e03ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72545}
      57062d6c
    • Paolo Severini's avatar
      [compiler] Re-reland "Faster JS-to-Wasm calls" · 831fa62b
      Paolo Severini authored 
      This is a reland of 6ada6a90

- Fixed a GC issue
  https://bugs.chromium.org/p/v8/issues/detail?id=11335:
  GC expected all arguments on the stack from code with
  CodeKind::TURBOFAN to be tagged objects. This is not the case now with
  inlined Wasm calls, and this information can be passed in
  SafepointEntry for each call site.

- Disabled JS-to-Wasm inlining for calls inside try/catch.

For more details, see updated doc:
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#

Bug: v8:11092


Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1b
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests).
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.


Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
> generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>

Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72541}
      831fa62b
  11. 04 Feb, 2021 2 commits
  13. 03 Feb, 2021 1 commit
  15. 02 Feb, 2021 5 commits
  17. 01 Feb, 2021 1 commit
  19. 29 Jan, 2021 4 commits
  21. 28 Jan, 2021 4 commits