1. 08 Sep, 2020 2 commits
  2. 28 Aug, 2020 1 commit
  3. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  4. 10 Jul, 2020 1 commit
  5. 20 Mar, 2020 2 commits
  6. 02 Mar, 2020 1 commit
  7. 20 Feb, 2020 1 commit
  8. 10 Feb, 2020 1 commit
  9. 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
  10. 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
  11. 02 Sep, 2019 1 commit
  12. 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
  13. 09 Aug, 2019 1 commit
  14. 08 Aug, 2019 1 commit
  15. 24 May, 2019 1 commit
  16. 23 May, 2019 2 commits
  17. 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
  18. 28 Feb, 2019 4 commits
    • Leszek Swirski's avatar
      [ignition] Use dead code elimination for implicit returns · 8d940b91
      Leszek Swirski authored
      Rather than manually tracking basic blocks in the bytecode array builder,
      use the existing dead code elimination to generate an implicit return iff
      the block ending the bytecode is not dead by the time all statements have
      been visited.
      
      Change-Id: I9520486a523ec4e01bc203e9a847eb1f57b130b6
      Reviewed-on: https://chromium-review.googlesource.com/c/1494756Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59951}
      8d940b91
    • Leszek Swirski's avatar
      Reland "[ignition] Skip binding dead labels" · c7ebc581
      Leszek Swirski authored
      This is a reland of 35269f77
      
      Switches on an expression that unconditionally throws would have all their
      case statements dead, causing a DCHECK error in the SwitchBuilder. This
      fixes up the DCHECK to allow dead labels.
      
      Original change's description:
      > [ignition] Skip binding dead labels
      >
      > BytecodeLabels for forward jumps may create a dead basic block if their
      > corresponding jump was elided (due to it dead code elimination). We can
      > avoid generating such dead basic blocks by skipping the label bind when
      > no corresponding jump has been observed. This works because all jumps
      > except JumpLoop are forward jumps, so we only have to special case one
      > Bind for loop headers to bind unconditionally.
      >
      > Since Binds are now conditional on a jump existing, we can no longer rely
      > on using Bind to get the current offset (e.g. at the beginning of a try
      > block). Instead, we now expose the current offset in the bytecode array
      > writer. Conveniently, this means that we can be a bit smarter about basic
      > blocks around these statements.
      >
      > As a drive-by, remove the unused Bind(target,label) function.
      >
      > Bug: chromium:934166
      > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
      > Reviewed-on: https://chromium-review.googlesource.com/c/1488763
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59942}
      
      TBR=rmcilroy@chromium.org
      
      Bug: chromium:934166
      Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4
      Reviewed-on: https://chromium-review.googlesource.com/c/1494535Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59948}
      c7ebc581
    • Sigurd Schneider's avatar
      Revert "[ignition] Skip binding dead labels" · 8ee20f5e
      Sigurd Schneider authored
      This reverts commit 35269f77.
      
      Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792
      
      Original change's description:
      > [ignition] Skip binding dead labels
      > 
      > BytecodeLabels for forward jumps may create a dead basic block if their
      > corresponding jump was elided (due to it dead code elimination). We can
      > avoid generating such dead basic blocks by skipping the label bind when
      > no corresponding jump has been observed. This works because all jumps
      > except JumpLoop are forward jumps, so we only have to special case one
      > Bind for loop headers to bind unconditionally.
      > 
      > Since Binds are now conditional on a jump existing, we can no longer rely
      > on using Bind to get the current offset (e.g. at the beginning of a try
      > block). Instead, we now expose the current offset in the bytecode array
      > writer. Conveniently, this means that we can be a bit smarter about basic
      > blocks around these statements.
      > 
      > As a drive-by, remove the unused Bind(target,label) function.
      > 
      > Bug: chromium:934166
      > Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
      > Reviewed-on: https://chromium-review.googlesource.com/c/1488763
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59942}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org
      
      Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:934166
      Reviewed-on: https://chromium-review.googlesource.com/c/1494534Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59947}
      8ee20f5e
    • Leszek Swirski's avatar
      [ignition] Skip binding dead labels · 35269f77
      Leszek Swirski authored
      BytecodeLabels for forward jumps may create a dead basic block if their
      corresponding jump was elided (due to it dead code elimination). We can
      avoid generating such dead basic blocks by skipping the label bind when
      no corresponding jump has been observed. This works because all jumps
      except JumpLoop are forward jumps, so we only have to special case one
      Bind for loop headers to bind unconditionally.
      
      Since Binds are now conditional on a jump existing, we can no longer rely
      on using Bind to get the current offset (e.g. at the beginning of a try
      block). Instead, we now expose the current offset in the bytecode array
      writer. Conveniently, this means that we can be a bit smarter about basic
      blocks around these statements.
      
      As a drive-by, remove the unused Bind(target,label) function.
      
      Bug: chromium:934166
      Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
      Reviewed-on: https://chromium-review.googlesource.com/c/1488763
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59942}
      35269f77
  19. 26 Feb, 2019 1 commit
  20. 25 Feb, 2019 1 commit
  21. 08 Nov, 2018 2 commits
    • Leszek Swirski's avatar
      [ignition] More accurate dead statement elision · 74125939
      Leszek Swirski authored
      The Ignition statement list visitor will skip the rest of the
      statements in the list if it hits a jump statement (like a return
      or break), as the rest of the code in the list can be considered
      dead.
      
          return;
          dead_call(); // skipped
      
      However, since this is at an AST node level, it does not take into
      account condition shortcutting:
      
          if(2.2) return;
          dead_call(); // not skipped
      
      There is also a second dead code elimination in Ignition compilation, at
      the bytecode array writer level, where a bytecodes are not emitted if an
      "exit" bytecode (Return, Jump, or a few others) has been written, until
      the next basic block starts (i.e. a Bind).
      
      This can cause an issue with statements that resurrect the bytecode
      array writer part-way through their visit. An example is try-catch
      statements, which save the context to a register, and then Bind to start
      the try region.
      
      For the case:
      
          if (2.2) return;
          try {     // try statement not skipped
              ...
          }
      
      the bytecode writer is called with
      
          OutputReturn()             // exit bytecode seen
          OutputMove(<context>, r1)  // not emitted
          Bind(&try_begin)           // starts new basic block
          // try body
      
      So, the try is emitted, but without saving the context to a register.
      This means that the liveness analysis sees the read of that register
      (as the output liveness of throwing bytecodes), but does not have a
      write to the register, which means that the liveness escapes.
      
      This patch fixes this by using the bytecode array writer dead-code
      elimination (i.e. "exit bytecode seen") to inform the statement list
      visitor, so that in this example the try statement is not visited at
      all.
      
      Bug: chromium:902395
      Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3
      Reviewed-on: https://chromium-review.googlesource.com/c/1322951Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57350}
      74125939
    • Jaroslav Sevcik's avatar
      [interpreter] Store CreateObjectLiteral's result into the accumulator. · 60c0edc0
      Jaroslav Sevcik authored
      As opposed to the register.
      
      For subtle reasons, this fixes a deoptimizer bug with handling return
      values in lazy deopt. Since the return values can now only overwrite
      the accumulator, there is no danger of overwriting a captured object
      that might be later used (since there is no "later").
      
      Bug: chromium:902608
      Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942
      Reviewed-on: https://chromium-review.googlesource.com/c/1325901Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57349}
      60c0edc0
  22. 05 Nov, 2018 1 commit
  23. 27 Sep, 2018 1 commit
    • Creddy's avatar
      Reland "[interpreter] Separate bytecodes for one-shot property loads and stores" · 0714bd9f
      Creddy authored
      This is a reland of eccf1867
      
      Original change's description:
      > [interpreter] Separate bytecodes for one-shot property loads and stores
      > 
      > Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
      > for one-shot property loads and stores. This CL replaces the runtime
      > calls with new bytecodes for named property load stores in one-shot code.
      > the runtime calls needed extra set of consecutive registers and
      > additional move instructions. This increased the size of
      > bytecode-array and possibly extended the life time of objects.
      > By replacing them with NoFeedback bytecodes we avoid these issues.
      > 
      > Bug: v8:8072
      > Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
      > Reviewed-on: https://chromium-review.googlesource.com/1196725
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Chandan Reddy <chandanreddy@google.com>
      > Cr-Commit-Position: refs/heads/master@{#56211}
      
      Bug: v8:8072
      Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
      Reviewed-on: https://chromium-review.googlesource.com/1245742
      Commit-Queue: Chandan Reddy <chandanreddy@google.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56266}
      0714bd9f
  24. 26 Sep, 2018 1 commit
    • Maya Lekova's avatar
      Revert "[interpreter] Separate bytecodes for one-shot property loads and stores" · 3c3330f6
      Maya Lekova authored
      This reverts commit eccf1867.
      
      Reason for revert: Speculative revert because it seems to introduce a pretty stable flake on gc stress tests, see https://bugs.chromium.org/p/v8/issues/detail?id=8229
      
      Original change's description:
      > [interpreter] Separate bytecodes for one-shot property loads and stores
      > 
      > Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
      > for one-shot property loads and stores. This CL replaces the runtime
      > calls with new bytecodes for named property load stores in one-shot code.
      > the runtime calls needed extra set of consecutive registers and
      > additional move instructions. This increased the size of
      > bytecode-array and possibly extended the life time of objects.
      > By replacing them with NoFeedback bytecodes we avoid these issues.
      > 
      > Bug: v8:8072
      > Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
      > Reviewed-on: https://chromium-review.googlesource.com/1196725
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Chandan Reddy <chandanreddy@google.com>
      > Cr-Commit-Position: refs/heads/master@{#56211}
      
      TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,cbruni@chromium.org,chandanreddy@google.com
      
      Change-Id: I445db58e6d4c275b434fabad5fad775bf259033f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8072
      Reviewed-on: https://chromium-review.googlesource.com/1245421Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56232}
      3c3330f6
  25. 25 Sep, 2018 1 commit
  26. 17 Sep, 2018 1 commit
  27. 14 Sep, 2018 1 commit
  28. 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
  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. 20 Jul, 2018 2 commits
    • Sigurd Schneider's avatar
      Revert "[cleanup] Rename {kLastErrorMessage} to {kNumberOfReasons}" · 9741c7e3
      Sigurd Schneider authored
      This reverts commit 29379945.
      
      Reason for revert: Needed for other revert:
      https://chromium-review.googlesource.com/c/v8/v8/+/1145431
      
      Original change's description:
      > [cleanup] Rename {kLastErrorMessage} to {kNumberOfReasons}
      > 
      > The name {kLastErrorMessage} is misleading, as it's not actually the
      > index of the last message (or reason), but one more (i.e. number of
      > messages / reasons). Thus this renaming.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:7754
      > Change-Id: Id21edcecac84c0e6068423c6124ef2881116dc7c
      > Reviewed-on: https://chromium-review.googlesource.com/1145305
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54593}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: I2af83f4a2299e05ad9bcacfe69c0b483fd1488de
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7754
      Reviewed-on: https://chromium-review.googlesource.com/1145520Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54596}
      9741c7e3
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored
      As discussed in
      https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
      
      this CL introduces a new bytecode (CloneObject), and a new IC type.
      
      In this prototype implementation, the type feedback looks like the
      following:
      
      Uninitialized case:
        { uninitialized_sentinel, uninitialized_sentinel }
      Monomorphic case:
        { weak 'source' map, strong 'result' map }
      Polymorphic case:
        { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
      Megamorphic case:
        { megamorphic_sentinel, cleared_Value }
      
      In the fast case, Object cloning is done by allocating an object with
      the saved result map, and a shallow clone of the fast properties from
      the source object, as well as cloned fast elements from the source object.
      If at any point the fast case can't be taken, the IC transitions to the
      slow case and remains there.
      
      This prototype CL does not include any TurboFan optimization, and the
      CloneObject operation is merely reduced to a stub call.
      
      It may still be possible to get some further improvements by somehow
      incorporating compile-time boilerplate elements into the cloned object,
      or simplifying how the boilerplate elements are inserted into the
      object.
      
      In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
      by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
      
      R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
      BUG=v8:7611
      
      Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
      Reviewed-on: https://chromium-review.googlesource.com/1127472
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58