1. 23 May, 2019 1 commit
  2. 21 May, 2019 1 commit
  3. 20 May, 2019 1 commit
  4. 15 May, 2019 1 commit
  5. 13 May, 2019 1 commit
  6. 10 May, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[class] implement private method declarations" · bf07d790
      Ross McIlroy authored
      This reverts commit b9191bd3.
      
      Reason for revert: Clusterfuzz bugs
      BUG=chromium:961507,chromium:961508
      
      Original change's description:
      > [class] implement private method declarations
      >
      > This patch implements the declarations of private methods, the access
      > of private methods would be left to a future patch.
      > When a private methods declaration is encountered, we now:
      >
      > - Create a brand symbol during class evaluation and store it in the
      >   context.
      > - Create the closures for the private methods
      > - Load the brand from the context and store it in the instance in the
      >   constructor.
      >
      > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
      >
      > Bug: v8:8330
      > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61387}
      
      TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
      
      Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8330
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61406}
      bf07d790
  7. 09 May, 2019 1 commit
  8. 12 Mar, 2019 1 commit
  9. 25 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Skip arguments adaptor when target cannot observe arguments. · 75629d5f
      Benedikt Meurer authored
      When calling a known function from optimized code, where the number of
      actual arguments does not match the number of expected arguments,
      TurboFan has to call indirectly via the arguments adaptor trampoline,
      which creates an argument adaptor frame underneath the activation record
      for the callee. This is done so that the callee can still get to the
      actual arguments, using either
      
      1. the arguments object, or
      2. rest parameters (to get to superfluous arguments), or
      3. the non-standard Function.arguments accessor (for sloppy mode
         functions), or
      4. direct eval(), where we don't know whether there's a use of the
         arguments object hiding somewhere in the string.
      
      However going through the arguments adaptor trampoline is quite
      expensive usually, it seems to be responsible for over 60% of the
      call overhead in those cases.
      
      So this adds a fast path for the case of calling strict mode functions
      where we have an arguments mismatch, but where we are sure that the
      callee cannot observe the actual arguments. We use a bit on the
      SharedFunctionInfo to indicate that this is safe, which is controlled
      by hints from the Parser which knows whether the callee uses either
      arguments object or rest parameters.
      
      In those cases we use a direct call from optimized code, passing the
      expected arguments instead of the actual arguments. This improves the
      benchmark on the document below by around 60-65%, which is exactly
      the overhead of the arguments adaptor trampoline that we save in this
      case.
      
      This also adds a runtime flag --fast_calls_with_arguments_mismatches,
      which can be used to turn off the new behavior. This might be handy
      for checking the performance impact via Finch.
      
      Bug: v8:8895
      Change-Id: Idea51dba7ee6cb989e86e0742eaf3516e5afe3c4
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch
      Reviewed-on: https://chromium-review.googlesource.com/c/1482735
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59825}
      75629d5f
  10. 15 Feb, 2019 1 commit
  11. 13 Feb, 2019 1 commit
    • Toon Verwaest's avatar
      [ast] Always visit all AST nodes, even dead nodes · 9439a1d2
      Toon Verwaest authored
      We'll let the bytecode compiler and optimizing compilers deal with dead code,
      rather than the ast visitors. The problem is that the visitors previously
      disagreed upon what was dead. That's bad if necessary visitors omit parts of
      the code that the bytecode generator will actually visit.
      
      I did consider removing the AST nodes immediately in the parser, but that
      adds overhead and actually broke code coverage. Since dead code shouldn't be
      shipped to the browser anyway (and we can still omit it later in the bytecode
      generator), I opted for keeping the nodes instead.
      
      Change-Id: Ib02fa9031b17556d2e1d46af6648356486f8433d
      Reviewed-on: https://chromium-review.googlesource.com/c/1470108
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59569}
      9439a1d2
  12. 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
  13. 28 Jan, 2019 1 commit
  14. 21 Dec, 2018 1 commit
  15. 07 Dec, 2018 3 commits
  16. 21 Nov, 2018 1 commit
  17. 05 Nov, 2018 1 commit
  18. 24 Oct, 2018 2 commits
  19. 23 Oct, 2018 1 commit
  20. 17 Oct, 2018 1 commit
  21. 05 Sep, 2018 1 commit
    • 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
  22. 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
  23. 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
  24. 05 Jul, 2018 1 commit
  25. 04 Jul, 2018 2 commits
  26. 02 Jul, 2018 1 commit
  27. 21 Jun, 2018 1 commit
  28. 29 May, 2018 1 commit
  29. 28 May, 2018 1 commit
  30. 14 May, 2018 1 commit
  31. 05 Apr, 2018 1 commit
  32. 12 Feb, 2018 1 commit
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
      which has been ratified and pulled into the specification. In particular,
      template callsite objects are no longer kept in a global, eternal Map, but
      are instead associated with their callsite, which can be collected. This
      prevents a memory leak incurred by TaggedTemplate calls.
      
      Changes, summarized:
      
          - Remove the TemplateMap and TemplateMapShape objects, instead caching
            template objects in the feedback vector.
          - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
            method (used by TemplateMap)
          - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
            to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
            that a new feedback vector is always created for eval() containing tagged
            templates, even when the CompilationCache is used.
          - GetTemplateObject bytecode now takes a feedback index, and only calls
            into the runtime if the feedback is Smi::kZero (uninitialized).
      
      BUG=v8:3230, v8:2891
      R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
      rmcilroy@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
      Reviewed-on: https://chromium-review.googlesource.com/624564
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00
  33. 29 Jan, 2018 1 commit
  34. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org
      TBR=neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
      Reviewed-on: https://chromium-review.googlesource.com/857593
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  35. 09 Jan, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored
      This reverts commit bf4cc9ee.
      
      Reason for revert: Breaks windows with msvc and linux with gcc
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
      
      Original change's description:
      > [esnext] load `iterator.next` only once at beginning of iteration
      > 
      > https://github.com/tc39/ecma262/pull/988 gained concensus during the
      > september 2017 TC39 meetings. This moves the load of the "next" method
      > to the very beginning of the iteration protocol, rather than during
      > each iteration step.
      > 
      > This impacts:
      > 
      > - yield*
      > - for-of loops
      > - spread arguments
      > - array spreads
      > 
      > In the v8 implementation, this also affects async iteration versions of
      > these things (the sole exception being the Async-From-Sync iterator,
      > which requires a few more changes to work with this, likely done in a
      > followup patch).
      > 
      > This change introduces a new AST node, ResolvedProperty, which can be used
      > as a callee by Call nodes to produce the same bytecode as Property calls,
      > without observably re-loading the property. This is used in several
      > AST-desugarings involving the iteration protocol.
      > 
      > BUG=v8:6861, v8:5699
      > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      > Reviewed-on: https://chromium-review.googlesource.com/687997
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50452}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
      
      Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6861, v8:5699
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      Reviewed-on: https://chromium-review.googlesource.com/687997
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee