1. 20 Feb, 2019 1 commit
  2. 02 Feb, 2019 1 commit
  3. 30 Jan, 2019 1 commit
  4. 29 Jan, 2019 2 commits
  5. 22 Jan, 2019 1 commit
  6. 16 Jan, 2019 1 commit
  7. 15 Jan, 2019 1 commit
    • Ben L. Titzer's avatar
      [wasm] Implement table.drop · 97cdf35f
      Ben L. Titzer authored
      The table.drop bytecode "drops" the backing storage for an element
      initializer. In the V8 implementation, this is a nop, other than
      updating a per-instance boolean array so that two drops of the same
      segment or a drop of an active segment will trap.
      
      This is implemented with inline code in TurboFan in order to be symmetric
      to memory.drop, but could as easily be a runtime call to be supported in
      Liftoff.
      
      R=mstarzinger@chromium.org
      CC=​binji@chromium.org
      BUG=v8:7747
      
      Change-Id: Ic017398eaa764dd3a9ff19523453ff7142c9abf6
      Reviewed-on: https://chromium-review.googlesource.com/c/1408996Reviewed-by: 's avatarBen Smith <binji@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58817}
      97cdf35f
  8. 08 Jan, 2019 1 commit
  9. 07 Jan, 2019 1 commit
  10. 17 Dec, 2018 1 commit
  11. 12 Dec, 2018 1 commit
    • Ben Smith's avatar
      [wasm] Implement memory.init and memory.drop · 4084185b
      Ben Smith authored
      `memory.init` copies bytes from a passive data segment to linear memory.
      
      `memory.drop` is an instruction that informs the wasm VM that the instance no
      longer needs access to the passive data segment.
      
      Information about the passive data segments, including their contents, length,
      and whether they are dropped, is stored in the `WasmInstanceObject` as primitive
      arrays.
      
      Bug: v8:7747
      Change-Id: I1515c8868c9be227743456a539126c15280b5365
      Reviewed-on: https://chromium-review.googlesource.com/c/1370691Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Ben Smith <binji@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58196}
      4084185b
  12. 11 Dec, 2018 1 commit
  13. 10 Dec, 2018 2 commits
  14. 30 Nov, 2018 1 commit
    • Peter Marshall's avatar
      Revert "[runtime] Reduce spread/apply call max arguments" · ff0cf00c
      Peter Marshall authored
      This reverts commit 4e3a17d0.
      
      Reason for revert: Web compact issues, see crbug.com/910252
      
      Original change's description:
      > [runtime] Reduce spread/apply call max arguments
      > 
      > Bug: chromium:906043
      > Change-Id: I308b29af0644c318d73926b27e65a94913c760c7
      > Reviewed-on: https://chromium-review.googlesource.com/c/1346115
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57731}
      
      TBR=jarin@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:906043
      Change-Id: I240c1b55c10fd3e108e3c49f93ce1d9ca9c61780
      Reviewed-on: https://chromium-review.googlesource.com/c/1356502Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57956}
      ff0cf00c
  15. 23 Nov, 2018 1 commit
    • Toon Verwaest's avatar
      [parser] Cleanup pattern classification · 2e052332
      Toon Verwaest authored
      This changes the split from AssignmentPattern and BindingPattern to Pattern and
      BindingPattern. Pattern collects all errors that are invalid in both assignment
      and binding pattern contexts. Binding pattern additionally collects errors for
      binding pattern contexts (property access isn't a valid target). The
      distinction is piggybacked on to distinguish assignment vs binding pattern
      errors since binding pattern verification will first throw the binding pattern
      error.
      
      Since we don't throw pattern error as binding pattern as well, this can mean
      that a later binding pattern syntax error will show up before an early pattern
      error. Since that just changes the message to another syntax violation, I think
      that's fine.
      
      Change-Id: Ib6a22c8d11c49eacc6667ae8ee5e98bababadd43
      Reviewed-on: https://chromium-review.googlesource.com/c/1349273Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57774}
      2e052332
  16. 22 Nov, 2018 1 commit
  17. 19 Nov, 2018 1 commit
  18. 12 Nov, 2018 1 commit
  19. 08 Nov, 2018 2 commits
  20. 05 Nov, 2018 1 commit
  21. 18 Oct, 2018 1 commit
  22. 17 Oct, 2018 1 commit
  23. 16 Oct, 2018 1 commit
  24. 11 Oct, 2018 1 commit
  25. 04 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] First prototype of zero-cost async stack traces. · f537d778
      Benedikt Meurer authored
      This introduces a new flag --async-stack-traces, which enables zero-cost
      async stack traces. This enriches the non-standard Error.stack property
      with async stack frames computed from walking up the promise chains and
      collecting all the await suspension points along the way. In Error.stack
      these async frames are marked with "async" to make it possible to
      distinguish them from regular frames, for example:
      
      ```
      Error: Some error message
          at bar (<anonymous>)
          at async foo (<anonymous>)
      ```
      
      It's zero-cost because no additional information is collected during the
      execution of the program, but only the information already present in the
      promise chains is used to reconstruct an approximation of the async stack
      in case of an exception. But this approximation is limited to suspension
      points at await's in async functions. This depends on a recent ECMAScript
      specification change, flagged behind --harmony-await-optimization and
      implied the --async-stack-traces flag. Without this change there's no
      way to get from the outer promise of an async function to the rest of
      the promise chain, since the link is broken by the indirection introduced
      by await.
      
      For async functions the special outer promise, named .promise in the
      Parser desugaring, is now forcible allocated to stack slot 0 during
      scope resolution, to make it accessible to the stack frame construction
      logic. Note that this first prototype doesn't yet work fully support
      async generators and might have other limitations.
      
      Bug: v8:7522
      Ref: nodejs/node#11865
      Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9
      Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
      Reviewed-on: https://chromium-review.googlesource.com/c/1256762
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56363}
      f537d778
  26. 19 Sep, 2018 1 commit
  27. 18 Sep, 2018 1 commit
  28. 05 Sep, 2018 2 commits
    • Deepti Gandluri's avatar
      [wasm] Add runtime checks for misaligned atomic accesses · 2fcf6da4
      Deepti Gandluri authored
      BUG: v8:6532, chromium:874809
      Change-Id: I55c00e8563741908cf0daf263152ce927ae18e7c
      Reviewed-on: https://chromium-review.googlesource.com/1205812
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarBen Smith <binji@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55666}
      2fcf6da4
    • Hai Dang's avatar
      Reland "[interpreter] Add bytecode for leading array spreads." · 5f8a4272
      Hai Dang authored
      This is a reland of 1c48d52b.
      
      It turned out that IterableToList doesn't always behave according to
      the ES operation with the same name. Specifically, it allows holey arrays
      to take its fast path, which produces an output array with holes where
      actually "undefined" elements should appear.
      
      This CL changes the version of IterableToList that is used for spreads
      (IterableToListWithSymbolLookup) such that holey arrays take the slow path.
      It also includes tests for such situations.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      >
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      >
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      >
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      >
      > Bug: v8:7980
      >
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      Bug: v8:7980
      Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1201882
      Commit-Queue: Hai Dang <dhai@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55639}
      5f8a4272
  29. 31 Aug, 2018 1 commit
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored
      This reverts commit 1c48d52b.
      
      Reason for revert: Clusterfuzz found something.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      > 
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      > 
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      > 
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      > 
      > Bug: v8:7980
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
      
      Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7980
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
  30. 30 Aug, 2018 1 commit
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored
      This CL improves the performance of creating [...a, b] or [...a].
      If the array literal has a leading spread, this CL emits the bytecode
      [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      is implemented by [IterableToListDefault] builtin to create the initial
      array for the leading spread. IterableToListDefault has a fast path to
      clone efficiently if the spread is an actual array.
      
      The bytecode generated is now shorter. Bytecode generation is refactored
      into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      from this optimization also.
      For now, turbofan also lowers the bytecode to the builtin.
      
      The idiomatic use of [...a] to clone the array a now performs better
      than a simple for-loop, but still does not match the performance of slice.
      
      Bug: v8:7980
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Commit-Queue: Hai Dang <dhai@google.com>
      Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
  31. 08 Aug, 2018 1 commit
  32. 02 Aug, 2018 1 commit
    • Jungshik Shin's avatar
      Accept Etc/GMT* as a valid time zone id. · 4343e1a9
      Jungshik Shin authored
      Etc/GMT* time zones are  listed in the INAN time zone database and
      they should be accepted as valid.
      
      This CL will be followed by a CL for moving time zone name checks to C++
      that will accept all the time zone names (e.g. EST5EDT, Hongkong, ROK, Zulu).
      
      Bug: chromium:364374
      Test: intl/date-format/timezone.js
      Test: mjsunit/regress/regress-crbug-364374
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: If0e5327d7e980504a9cb3d2b641e907ebce61180
      Reviewed-on: https://chromium-review.googlesource.com/1159546
      Commit-Queue: Jungshik Shin <jshin@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54879}
      4343e1a9
  33. 25 Jul, 2018 1 commit
  34. 18 Jul, 2018 3 commits