1. 13 Dec, 2018 1 commit
  2. 08 Dec, 2018 1 commit
  3. 30 Nov, 2018 1 commit
  4. 28 Nov, 2018 1 commit
  5. 27 Nov, 2018 1 commit
  6. 23 Nov, 2018 1 commit
  7. 20 Nov, 2018 1 commit
  8. 19 Nov, 2018 1 commit
  9. 16 Nov, 2018 1 commit
  10. 15 Nov, 2018 1 commit
  11. 13 Nov, 2018 1 commit
  12. 12 Nov, 2018 1 commit
  13. 26 Oct, 2018 1 commit
  14. 24 Oct, 2018 1 commit
  15. 19 Sep, 2018 1 commit
    • Clemens Hammacher's avatar
      [base] Remove OffsetFrom and AddressFrom · 60d6f7c2
      Clemens Hammacher authored
      Those two methods are spread over the code base, and their purpose is
      often not clear. Historically, they were used to turn pointers into
      integers in order to do computations on them. Today we have {Address}
      which is uintptr_t, so we can compute directly on that.
      
      This also makes the {RoundUp} and {RoundDown} macros only work on
      integral values (including {Address}).
      
      R=mlippautz@chromium.org
      
      Bug: v8:8015
      Change-Id: Ia98fb826793ee5d3a2a5b18c09c329d088443772
      Reviewed-on: https://chromium-review.googlesource.com/1233914Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56048}
      60d6f7c2
  16. 17 Sep, 2018 1 commit
  17. 13 Sep, 2018 1 commit
  18. 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
  19. 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
  20. 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
  21. 28 Aug, 2018 1 commit
  22. 14 Aug, 2018 1 commit
  23. 25 Jul, 2018 1 commit
    • Benedikt Meurer's avatar
      [ic] Remember the receiver map in PREMONOMORPHIC state. · 8ba8a139
      Benedikt Meurer authored
      When going to PREMONOMORPHIC state we previously stored the
      premonomorphic sentinel into the first IC slot and then the
      second slot was storing the uninitialized sentinel. So when
      TurboFan kicked in and optimized the function we'd just put
      a LOAD_IC in there and hoped for the best that this is either
      not in hot code or will reoptimize for another reason later
      to fixup the LOAD_IC.
      
      This is a quite annoying footgun for developers because the
      performance inevitably depends on timing of when the optimizing
      compiler kicks in.
      
      To fix this issue we now keep a weak reference to the receiver
      map in the second slot of the IC in PREMONOMORPHIC state and
      use that to speculatively optimize when we go to TurboFan. This
      improves the performance on the reported bug from
      
        spread: 2342 ms.
        spread: 2352 ms.
        spread: 2339 ms.
      
      to
      
        spread: 1490 ms.
        spread: 1451 ms.
        spread: 1445 ms.
      
      which corresponds to a 36% improvement in this particular case.
      In general you'll get more predictable performance with this
      change.
      
      We might want to also use the map when going to MONOMORPHIC
      state at a later point to maybe skip the additional transition
      to POLYMORPHIC in some cases, but that's independent of this
      bug.
      
      Bug: v8:5267, v8:7973
      Change-Id: Ia4eef7651e219a40927531cdffe320ade1dd19a4
      Reviewed-on: https://chromium-review.googlesource.com/1148205Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54682}
      8ba8a139
  24. 20 Jul, 2018 1 commit
    • 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
  25. 02 Jul, 2018 1 commit
  26. 26 Jun, 2018 1 commit
  27. 15 Jun, 2018 1 commit
  28. 23 May, 2018 1 commit
  29. 18 May, 2018 1 commit
  30. 17 May, 2018 1 commit
  31. 14 May, 2018 1 commit
  32. 08 May, 2018 1 commit
  33. 30 Apr, 2018 1 commit
  34. 19 Apr, 2018 2 commits
  35. 09 Mar, 2018 1 commit
    • Peter Marshall's avatar
      [memory] Save space in the FeedbackMetadata on 64 bit platforms. · 5a70a5ea
      Peter Marshall authored
      Previously we used a FixedArray for the FeedbackMetadata, packing bits
      of information into Smi fields. On 64-bit platforms, we waste at least
      half of the available memory by using the Smi representation.
      
      Given that this is just raw data (no pointers), we can just use a new
      type that uses the existing packing scheme to store the data in int32
      format instead.
      
      This CL changes FeedbackMetadata to a new subclass of HeapObject. This
      is to reduce the API surface exposed, in comparison to extending/using
      a more general purpose data structure like ByteArray, which is also just
      raw data.
      
      FeedbackMetadata only exposes general purpose methods for accessing
      slots, but hides the implementation detail of packing bits into int32
      fields.
      
      This CL also introduces a sentinal EmptyFeedbackMetadata, because there
      are ~750 empty FeedbackMetadata objects when running an empty program in
      V8. These are probably for builtins.
      
      Bug: v8:7500
      Change-Id: Ic85563153abbd71a22854cee8519260c32b1e9ab
      Reviewed-on: https://chromium-review.googlesource.com/945730
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51842}
      5a70a5ea
  36. 05 Mar, 2018 3 commits
  37. 02 Mar, 2018 1 commit