1. 29 Nov, 2017 2 commits
  2. 28 Nov, 2017 1 commit
  3. 17 Oct, 2017 1 commit
  4. 02 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize TypedArray.prototype[Symbol.toStringTag]. · b8b76eba
      Benedikt Meurer authored
      The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
      as far as I can tell only definitely side-effect free) way to check whether an
      arbitrary object is a TypedArray - either generally TypedArray or a specific
      one like Uint8Array. Using the getter is thus emerging as the general pattern
      to detect TypedArrays, even Node.js now adapted it starting with
      
        https://github.com/nodejs/node/pull/15663
      
      for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
      now.
      
      The getter returns either the string with the TypedArray subclass name
      (i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
      This can be implemented with a simple elements kind dispatch, instead of
      checking the instance type and then loading the class name from the
      constructor, which requires a loop walking up the transition tree. This
      CL ports the builtin to CSA and TurboFan, and changes the logic to a
      simple elements kind check. On the micro-benchmark mentioned in the
      referenced bug, the time goes from
      
        testIsArrayBufferView: 565 ms.
        testIsTypedArray: 2403 ms.
        testIsUint8Array: 3847 ms.
      
      to
      
        testIsArrayBufferView: 566 ms.
        testIsTypedArray: 965 ms.
        testIsUint8Array: 965 ms.
      
      which presents an up to 4x improvement.
      
      Bug: v8:6874
      Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
      Reviewed-on: https://chromium-review.googlesource.com/695021Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48254}
      b8b76eba
  5. 15 Sep, 2017 1 commit
  6. 13 Sep, 2017 1 commit
  7. 06 Sep, 2017 2 commits
  8. 01 Sep, 2017 1 commit
  9. 31 Aug, 2017 1 commit
  10. 18 Aug, 2017 2 commits
  11. 17 Aug, 2017 1 commit
  12. 16 Aug, 2017 2 commits
  13. 14 Aug, 2017 1 commit
  14. 20 Jul, 2017 1 commit
  15. 19 Jul, 2017 1 commit
  16. 28 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [runtime] Cleanup native methods creation in js/typedarray.js. · eb735f3d
      Igor Sheludko authored
      This CL replaces usages of utils.InstallFunctions and utils.InstallGetter()
      with the DEFINE_METHOD* macros that ensure that the native function is
      created in proper form from the beginning. Thus the function will not
      require further reconfiguring like adding a computed name or removing of
      'prototype' property.
      
      This CL is one of a series of cleanup CL which are the preliminary steps for
      improving function closures creation.
      
      Bug: v8:6459
      Change-Id: I8432be211adf104cacb74ba2431364bfd6614d18
      Reviewed-on: https://chromium-review.googlesource.com/548177
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46297}
      eb735f3d
  17. 22 May, 2017 1 commit
  18. 19 May, 2017 1 commit
  19. 02 May, 2017 1 commit
  20. 27 Apr, 2017 1 commit
  21. 26 Apr, 2017 1 commit
  22. 24 Apr, 2017 1 commit
  23. 19 Apr, 2017 2 commits
  24. 10 Apr, 2017 1 commit
    • Peter Marshall's avatar
      [runtime] Fix spec bug in TypedArrayConstruct with mutating iterables. · cc75535d
      Peter Marshall authored
      The spec requires that we use IterableToList, which we skipped for
      some arrays as an optimization. We can't skip this for arrays with
      objects though, because the objects may mutate the array during
      the copying step via valueOf side effects.
      
      Also clean up the implementation to use a runtime function rather
      than a builtin as the helper. Also reverses the result of the helper
      because I think it is a bit more intuitive that way.
      
      Bug: v8:6224
      Change-Id: I9199491abede4479785df6d9068331bc2d6e9c5e
      Reviewed-on: https://chromium-review.googlesource.com/471986Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44507}
      cc75535d
  25. 08 Apr, 2017 1 commit
  26. 04 Apr, 2017 2 commits
  27. 03 Apr, 2017 1 commit
  28. 01 Apr, 2017 1 commit
  29. 31 Mar, 2017 2 commits
    • Peter Marshall's avatar
      [builtins] Skip iteration when constructing TypedArrays if possible. · 143dcc6c
      Peter Marshall authored
      This CL uses the same logic as spread calls to check whether the
      iteration over an array would produce different results to simply
      accessing the backing store directly. Skipping the full iteration
      protocol for normal arrays gives us a ~10x speedup on the
      construct-typedarray benchmark.
      
      BUG=v8:5977,v8:5699,v8:4782,chromium:698173
      
      Change-Id: Ib878d39691e99b739afef0dd05a6a6efc5b6b5d4
      Reviewed-on: https://chromium-review.googlesource.com/463367Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44304}
      143dcc6c
    • Peter Marshall's avatar
      [builtins] Copy array contents using JS in ConstructByArrayLike. · a450c185
      Peter Marshall authored
      The last CL https://chromium-review.googlesource.com/c/456707/ caused
      some pretty heavy performance regressions. After experimenting, it
      seems the easiest and most straight-forward way to copy the elements
      into the new typed array is to do it in JS.
      
      Adds a fast path for typed arrays, where the source typed array has
      the same elements kind, in which case we can just copy the backing
      store using memcpy.
      
      This CL also removes regression test 319120 which is from a pwn2own
      vulnerability. The old code path enforced a maximum byte_length
      that was too low, which this change removes. The length property of
      the typed array must be a Smi, but the byte_length, which can be up
      to 8x larger than length for a Float64Array, can be a heap number.
      
      We can also re-use some of the logic from ConstructByLength when
      deciding whether to allocate the buffer on- or off-heap, so that
      is factored out into InitializeBasedOnLength. We can also re-use
      the DoInitialize helper instead of calling into the runtime,
      meaning we can remove InitializeFromArrayLike.
      
      BUG=v8:5977,chromium:705503,chromium:705394
      
      Change-Id: I63372652091d4bdf3a9491acef9b4e3ac793a755
      Reviewed-on: https://chromium-review.googlesource.com/459621Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44301}
      a450c185
  30. 30 Mar, 2017 1 commit
  31. 25 Mar, 2017 1 commit
  32. 24 Mar, 2017 2 commits