1. 24 Sep, 2019 1 commit
  2. 20 Sep, 2019 1 commit
  3. 12 Sep, 2019 1 commit
  4. 06 Sep, 2019 1 commit
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored
      This is a reland of 8b89a7c3
      
      Reland after disabling the test getting deadlocked with '--gc_stress' flag.
      The CL was reverted because of the 'wasm/grow-shared-memory' test from
      the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
      the known issue (v8:9221) and the deadlocking test is now disabled (
      https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).
      
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      >
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      >
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      Bug: v8:9489,v8:9221
      Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
  5. 03 Sep, 2019 2 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored
      This reverts commit 8b89a7c3.
      
      Reason for revert: GC Stress tests timing out.
      See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      > 
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      > 
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
      
      Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9489
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored
      The functionality of the GetIterator bytecode introduced previously is
      now extended from loading the @@iterator property to calling the property
      as well. This change basically absorbs the functionality of additional
      two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      Importantly, this change handles the cases of eager and lazy deoptimization
      in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      This mechanism can work as a template for the future bytecode that require
      handling such inter-bytecode deopt scenario. The tests evaluating the eager
      and lazy deopt scenarios are also included.
      
      Bug: v8:9489
      Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3
  6. 02 Sep, 2019 1 commit
  7. 30 Aug, 2019 2 commits
    • Leszek Swirski's avatar
      Reland "[destructuring] Elide coercible check for simple keys" · ef2df57a
      Leszek Swirski authored
      This is a reland of 1fba0441
      Chromium expectation tests have been disabled, and will be enabled
      
      Original change's description:
      > [destructuring] Elide coercible check for simple keys
      >
      > Simple object destructuring, such as `let {a,b} = o`, is less efficient
      > than the equivalent assignments `let a = o.a; let b = o.b`. This is
      > because it does a nil check of `o` before the assignments. However, this
      > nil check is not strictly necessary for simple (i.e. non-computed) names,
      > as there will be an equivalent nil check on the first access to o in
      > `o.a`. For computed names the computation is unfortunately obervable.
      >
      > So, we can elide the nil check when the first property (if any) of the
      > destructuring target is a non-computed name. This messes a bit with our
      > error messages, so we re-use the CallPrinter to also find destructuring
      > assignment based errors, and fiddle with the error message there. As
      > a side-effect, we also get out the object name in the AST, so we can
      > output a slightly nicer error message.
      >
      > Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63453}
      
      TBR=verwaest@chromium.org
      
      Bug: chromium:999473
      Change-Id: Ib0b2e4be433c50521ba1722e1c06b672bfefa405
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777702Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63477}
      ef2df57a
    • Joyee Cheung's avatar
      [class] implement private accessors · df12eb19
      Joyee Cheung authored
      This patch implements the access of private accessors by loading the
      referenced component from the AccessorPair associated with private
      name variables. It also makes the error messages for invalid kind
      of private accessor access more specific.
      
      Bug: v8:8330
      Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
      
      Change-Id: I6d441cffb85f8d9cd0417ec9b6ae20f3e34ef418
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695205Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#63474}
      df12eb19
  8. 29 Aug, 2019 2 commits
    • Adam Klein's avatar
      Revert "[destructuring] Elide coercible check for simple keys" · 28fa4cb4
      Adam Klein authored
      This reverts commit 1fba0441.
      
      Reason for revert: blocks V8 roll due to layout test failures caused by error message changes:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/347
      
      Original change's description:
      > [destructuring] Elide coercible check for simple keys
      > 
      > Simple object destructuring, such as `let {a,b} = o`, is less efficient
      > than the equivalent assignments `let a = o.a; let b = o.b`. This is
      > because it does a nil check of `o` before the assignments. However, this
      > nil check is not strictly necessary for simple (i.e. non-computed) names,
      > as there will be an equivalent nil check on the first access to o in
      > `o.a`. For computed names the computation is unfortunately obervable.
      > 
      > So, we can elide the nil check when the first property (if any) of the
      > destructuring target is a non-computed name. This messes a bit with our
      > error messages, so we re-use the CallPrinter to also find destructuring
      > assignment based errors, and fiddle with the error message there. As
      > a side-effect, we also get out the object name in the AST, so we can
      > output a slightly nicer error message.
      > 
      > Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63453}
      
      TBR=leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I74cf06ebd987e5b8bbe1831b0042c085edf37f5b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776994Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63465}
      28fa4cb4
    • Leszek Swirski's avatar
      [destructuring] Elide coercible check for simple keys · 1fba0441
      Leszek Swirski authored
      Simple object destructuring, such as `let {a,b} = o`, is less efficient
      than the equivalent assignments `let a = o.a; let b = o.b`. This is
      because it does a nil check of `o` before the assignments. However, this
      nil check is not strictly necessary for simple (i.e. non-computed) names,
      as there will be an equivalent nil check on the first access to o in
      `o.a`. For computed names the computation is unfortunately obervable.
      
      So, we can elide the nil check when the first property (if any) of the
      destructuring target is a non-computed name. This messes a bit with our
      error messages, so we re-use the CallPrinter to also find destructuring
      assignment based errors, and fiddle with the error message there. As
      a side-effect, we also get out the object name in the AST, so we can
      output a slightly nicer error message.
      
      Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63453}
      1fba0441
  9. 26 Aug, 2019 1 commit
  10. 23 Aug, 2019 1 commit
    • Dan Elphick's avatar
      [compiler] Skip creating unneeded objects for lazy source positions · 735f3a68
      Dan Elphick authored
      This changes Compiler::CollectSourcePositions to skip finalization of
      the BytecodeArray, constant table, handler table, ScopeInfos as well as
      internalization of Ast values since only the source position table is
      used and the others will be collected soon after by the GC.
      
      It will also now avoid recompiling inner functions that would otherwise
      be eagerly compiled.
      
      BytecodeArrayWriter::ToBytecodeArray has been changed to never populate
      the source_position_table.
      
      Bug: v8:8510
      Change-Id: I2db2f2da6b48fde11f17a20d017c1a54c0a34fc2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763538
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63365}
      735f3a68
  11. 21 Aug, 2019 1 commit
  12. 20 Aug, 2019 1 commit
  13. 19 Aug, 2019 1 commit
  14. 12 Aug, 2019 1 commit
  15. 09 Aug, 2019 1 commit
  16. 08 Aug, 2019 1 commit
  17. 07 Aug, 2019 2 commits
  18. 30 Jul, 2019 1 commit
    • Joyee Cheung's avatar
      [class] parse private accessors · a6dd7f1c
      Joyee Cheung authored
      This patch adds:
      
      - VariableMode::kPrivateMethod
      - VariableMode::kPrivateSetterOnly
      - VariableMode::kPrivateGetterOnly
      - VariableMode::kPrivateGetterAndSetter
      
      And replace the previous RequiresBrandCheckFlag by inferring
      whether the brand check is required from these VariableModes.
      It is then possible to check duplicate non-complementary
      accessors in the parsers and throw early errors, and allow
      complementary accessors to be associated with the same
      private name variable.
      
      This patch also adds the following AssignType:
      
      - PRIVATE_METHOD
      - PRIVATE_GETTER_ONLY
      - PRIVATE_SETTER_ONLY
      - PRIVATE_GETTER_AND_SETTER
      
      corresponding to the new VariableModes so that it's possible
      to generate specialized code for different type of
      private accessor declarations.
      
      Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
      
      Bug: v8:8330
      Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62988}
      a6dd7f1c
  19. 20 Jun, 2019 1 commit
  20. 19 Jun, 2019 2 commits
  21. 18 Jun, 2019 1 commit
  22. 08 Jun, 2019 1 commit
    • Benedikt Meurer's avatar
      [interpreter] Do ToObject implicitly as part of CloneObject. · 92c6af8a
      Benedikt Meurer authored
      The CloneObject bytecode was only able to handle objects, null and
      undefined, and explicit bytecode had to be generated to perform the
      ToObject outside the bytecode (unlike the other IC bytecodes that
      just perform the ToObject implicitly). That means the simplest possible
      object cloning would also generate a sequence of 5 bytecodes (at least):
      
      ```
         Mov <register>, a0
         JumpIfNull @1
         JumpIfUndefined @1
         ToObject <register>
      1: CloneObject <register>
      ```
      
      That is quite wasteful and unnecessary, since the core logic in the
      runtime already does the ToObject properly anyways. This change
      refactors the CloneObjectIC slightly to behave more like the other ICs
      and do the ToObject implicitly when necessary.
      
      Bug: v8:7611, v8:9114, v8:9183, v8:9343
      Change-Id: I11973e90bf875f154a5a7739287bee17041e4a7a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649554Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62064}
      92c6af8a
  23. 06 Jun, 2019 1 commit
  24. 23 May, 2019 1 commit
  25. 21 May, 2019 1 commit
  26. 17 May, 2019 1 commit
  27. 16 May, 2019 3 commits
  28. 13 May, 2019 1 commit
  29. 10 May, 2019 2 commits
  30. 09 May, 2019 2 commits
  31. 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