1. 21 May, 2019 1 commit
  2. 17 May, 2019 1 commit
  3. 16 May, 2019 3 commits
  4. 13 May, 2019 1 commit
  5. 10 May, 2019 2 commits
  6. 09 May, 2019 2 commits
  7. 29 Apr, 2019 1 commit
    • Benedikt Meurer's avatar
      [runtime] Optimize general object spread. · 4995c85f
      Benedikt Meurer authored
      This adds a new %_CopyDataProperties intrinsic, that reuses most of the
      existing machinery that we already have in place for Object.assign() and
      computed property names in object literals. This speeds up the general
      case for object spread (where the spread is not the first item in an
      object literal) and brings it on par with Object.assign() at least - in
      most cases it's significantly faster than Object.assign().
      
      In the test case [1] referenced from the bug, the performance goes from
      
        objectSpreadLast: 3624 ms.
        objectAssignLast: 1938 ms.
      
      to
      
        objectSpreadLast: 646 ms.
        objectAssignLast: 1944 ms.
      
      which corresponds to a **5-6x performance boost**, making object spread
      faster than Object.assign() in general.
      
      Drive-by-fix: This refactors the Object.assign() fast-path in a way that
      it can be reused appropriately for object spread, and adds another new
      builtin SetDataProperties, which does the core of the Object.assign()
      work. We can teach TurboFan to inline Object.assign() based on the new
      SetDataProperties builtin at some later point to further optimize
      Object.assign().
      
      [1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0
      
      Bug: v8:9167
      Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61100}
      4995c85f
  8. 03 Apr, 2019 2 commits
  9. 12 Mar, 2019 1 commit
  10. 11 Mar, 2019 2 commits
  11. 01 Mar, 2019 1 commit
    • Matt Gardner's avatar
      Reland "Optimize `in` operator" · 803ad324
      Matt Gardner authored
      The original was reverted for breaking webkit layout tests:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
      
      It also caused the following clusterfuzz failures:
      
      chromium:935832
      This was a correctness bug due to not properly handling the case of arrays with prototypes other
      than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
      holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
      both in access-assembler and in Turbofan.
      
      chromium:935932
      This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
      code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
      debug builds but in release could show up in different places. This is the bug that caused the
      webkit layout test failure that led to the revert.
      
      Both bugs are fixed by in CL, and tests are added for those cases.
      
      Bug: v8:8733, chromium:935932, chromium:935832
      Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
      Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Matt Gardner <magardn@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#59958}
      803ad324
  12. 28 Feb, 2019 1 commit
  13. 26 Feb, 2019 1 commit
  14. 25 Feb, 2019 2 commits
  15. 08 Feb, 2019 1 commit
  16. 06 Feb, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Handle 'this' with a special ThisExpression rather than VariableProxy · 3f2b5017
      Toon Verwaest authored
      "this" is a very common expression. By using a single ThisExpression object
      we can both avoid allocating many unnecessary VariableProxies and specialize
      the resolution of this since we know where it's declared up-front. This also
      avoids having to special-case "this" reference handling in the paths that would
      behave differently for "this" than for regular references; e.g., with-scopes.
      
      The tricky pieces are due to DebugEvaluate and this/super() used as default
      parameters of arrow functions. In the former case we replace the WITH_SCOPE
      with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still
      rely on regular dynamic variable lookup. Arrow functions are dealt with by
      marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression
      ends up being an arrow function, we force context allocate on the outer scope
      (and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the
      arrow function can expose "this").
      
      The CL also removes the now unused ThisFunction AST node.
      
      Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef
      Reviewed-on: https://chromium-review.googlesource.com/c/1448313Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59393}
      3f2b5017
  17. 04 Feb, 2019 1 commit
  18. 25 Jan, 2019 2 commits
  19. 22 Jan, 2019 2 commits
  20. 16 Jan, 2019 2 commits
  21. 15 Jan, 2019 1 commit
  22. 14 Jan, 2019 1 commit
  23. 10 Jan, 2019 3 commits
    • Leszek Swirski's avatar
      [destructuring] Get non-coercible message contents in runtime · 5e2c23e2
      Leszek Swirski authored
      For desrtucturing assignments from null/undefined, we throw an error
      that references the destructuring object literal's property name, e.g.
      for
        var { x } = null;
      we report that we cannot destructure 'x' from null.
      
      Rather than calculating this property during bytecode generation (and
      including it in the bytecode as an argument to the type error
      constructor), we can calculate it at exception throwing time, by
      re-parsing the source in a similar way to the existing call site
      rendering.
      
      This slightly decreases bytecode size and slightly decreases the amount
      of work the bytecode compiler needs to do. In the future, it could also
      allow us to give more detailed error messages, as we now have access to
      the entire AST and are on the slow path anyway.
      
      Bug: v8:6499
      Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72
      Reviewed-on: https://chromium-review.googlesource.com/c/1396080Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58706}
      5e2c23e2
    • Leszek Swirski's avatar
      [ignition] Remove useless iterator 'done' setting · f9a858fc
      Leszek Swirski authored
      The 'done' setting dance in BuildFillArrayWithIterator turned out to
      not be useful, as the StoreInArrayLiteral call could not ever throw an
      exception. Since iterator exceptions count as done, we are guarnteed to
      be done as soon as we enter the loop.
      
      Change-Id: Ibe2ba1fcbe383bfcfedb185169890b6931cc7884
      Reviewed-on: https://chromium-review.googlesource.com/c/1402792
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58695}
      f9a858fc
    • Leszek Swirski's avatar
      [ignition] Fix iteration finalization exception suppression · 7fbbce5f
      Leszek Swirski authored
      The IteratorClose spec specifies that exceptions in
      %GetMethod(iterator.return) are not suppressed by exceptions in the
      given continuation (body of a loop, assignments in destructuring),
      while exceptions in the execution of iterator.return() are.
      
      This means that we have to split out the property access + a typeof
      check to be outside the try-catch, and keep the call inside of it.
      
      The non-split version is only for cases when there is no 'throws'
      continuation (as is the case for yield* calling IteratorClose), so
      the existing BuildIteratorClose can be renamed to reflect this.
      
      Change-Id: Id71aea4fddd6ffb986bd9aaa09d29615a8800f71
      Reviewed-on: https://chromium-review.googlesource.com/c/1402789Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58694}
      7fbbce5f
  24. 09 Jan, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Don't desugar destructuring declarations. · 5e725a2b
      Leszek Swirski authored
      Emit a single destructuring assignment for destructuring declarations,
      which can be desugared by the bytecode generator. This allows us to
      remove destructuring desugaring from the parser (specifically, the
      pattern rewriter) entirely.
      
      The pattern "rewriter" is now only responsible for walking the
      destructuring pattern to declare variables, mark them assigned, and
      potentially rewrite scopes for the edge case of parameters with a sloppy
      eval.
      
      Note that since the rewriter is no longer rewriting, we have to flip the
      VariableProxy copying logic for var re-lookup, so that we now pass the
      new VariableProxy to the variable declaration and leave the original
      unresolved (rather than passing the original through and rewriting to a
      new unresolved VariableProxy).
      
      This change does have some effect on breakpoint locations, due to some
      of the available information changing between the parser and bytecode
      generator, however the new locations appear to be more consistent
      between assignments and declarations.
      
      Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82
      Reviewed-on: https://chromium-review.googlesource.com/c/1382462
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58670}
      5e725a2b
  25. 08 Jan, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Disambiguate variables through expression-scope · f9529f6b
      Toon Verwaest authored
      Previously we'd always push variable proxies into the unresolved list of the
      current scope, and possibly delete them from the list later in case they end up
      being declarations. If variables become assigned, there were two ways to mark
      them as such: The preparser would marked the variables tracked on the
      PreParserExpression, and the parser would traverse the LHS AST to find and mark
      all variables.
      
      After this CL, if the scope already knows it's tracking declarations, the
      variables are never added to the unresolved list in the first place. If the
      scope is ambigous, it tracks the variable proxies on the side and only adds
      them to the unresolved list if they end up being references rather than
      declarations. The same list is now used to bulk mark all LHS variables as
      assigned; uniformely for both the parser and the preparser.
      
      In a next step we'll also use the scope to create declarations. That way we can
      stop tracking variables_ on PreParserExpression altogether.
      
      Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f
      Reviewed-on: https://chromium-review.googlesource.com/c/1397669
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58629}
      f9529f6b
  26. 07 Jan, 2019 3 commits