1. 26 Jun, 2019 1 commit
  2. 29 May, 2019 1 commit
  3. 28 May, 2019 1 commit
  4. 23 May, 2019 2 commits
  5. 20 May, 2019 2 commits
  6. 26 Dec, 2018 1 commit
  7. 08 Dec, 2018 1 commit
  8. 25 Nov, 2018 1 commit
  9. 23 Nov, 2018 1 commit
  10. 20 Sep, 2018 1 commit
  11. 04 Sep, 2018 1 commit
    • Mike Stanton's avatar
      [builtins] Enable Torque Array.prototype.splice · fd334b32
      Mike Stanton authored
      Before, splice was implemented with a C++ fast path and a
      comprehensive JavaScript version.
      
      This impl. is entirely in Torque with a fastpath for SMI,
      DOUBLE and OBJECT arrays, and a comprehensive slow path.
      The same level of "sparse" array support as given by the
      array.js implementation is included.
      
      This reland addresses several issues:
      
      * Removed "sparse" array support from splice.
      * Addressed ClusterFuzz issue 876443:
        The test and code that uses the fix is in this CL.
        The fix in isolation can be seen here:
        https://chromium-review.googlesource.com/c/v8/v8/+/1199403
      * Removed dead code in elements.cc
      
      BUG=chromium:876443, v8:8131, v8:1956, v8:7221
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1
      Reviewed-on: https://chromium-review.googlesource.com/1201783
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55610}
      fd334b32
  12. 30 Jul, 2018 1 commit
  13. 23 Jul, 2018 1 commit
  14. 18 Jul, 2018 1 commit
  15. 26 Jun, 2018 1 commit
  16. 21 Jun, 2018 1 commit
  17. 09 Apr, 2018 1 commit
  18. 06 Apr, 2018 1 commit
  19. 04 Apr, 2018 2 commits
    • Ben Titzer's avatar
      Revert "[wasm] Merge the WasmContext into WasmInstanceObject" · 8adb94fc
      Ben Titzer authored
      This reverts commit 57bf0bfe.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] Merge the WasmContext into WasmInstanceObject
      > 
      > This change makes lifetime management of WasmCode much simpler.
      > By using the WasmInstanceObject as the context for WASM code execution,
      > including the pointer to the memory base and indirect function tables,
      > this keeps the instance alive when WASM code is on the stack, since
      > the instance object is passed as a parameter and spilled onto the stack.
      > This is in preparation of sharing the code between instances and
      > isolates.
      > 
      > Bug: v8:7424
      > 
      > Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      > Reviewed-on: https://chromium-review.googlesource.com/958520
      > Commit-Queue: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52361}
      
      TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7424
      Reviewed-on: https://chromium-review.googlesource.com/995418Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52364}
      8adb94fc
    • Ben L. Titzer's avatar
      [wasm] Merge the WasmContext into WasmInstanceObject · 57bf0bfe
      Ben L. Titzer authored
      This change makes lifetime management of WasmCode much simpler.
      By using the WasmInstanceObject as the context for WASM code execution,
      including the pointer to the memory base and indirect function tables,
      this keeps the instance alive when WASM code is on the stack, since
      the instance object is passed as a parameter and spilled onto the stack.
      This is in preparation of sharing the code between instances and
      isolates.
      
      Bug: v8:7424
      
      Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      Reviewed-on: https://chromium-review.googlesource.com/958520
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52361}
      57bf0bfe
  20. 26 Feb, 2018 1 commit
  21. 21 Feb, 2018 1 commit
  22. 10 Jan, 2018 1 commit
  23. 27 Nov, 2017 2 commits
  24. 07 Nov, 2017 1 commit
  25. 19 Oct, 2017 1 commit
  26. 18 Oct, 2017 1 commit
  27. 13 Oct, 2017 1 commit
  28. 11 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Add fast-path for JSTypedArray to CreateListFromArrayLike. · f31bae03
      Benedikt Meurer authored
      It's quite common today to use Function#apply together with typed
      arrays, for example to construct a String from character codes (or code
      points) within a Uint8Array or Uint16Array, i.e.
      
        String.fromCharCode.apply(undefined, uint8array)
      
      is seen quite often on the web. But there are other interesting cases
      like
      
        Math.max.apply(undefined, float64array)
      
      to compute the maximum value in a Float64Array, which is definitely not
      the fastest implementation, but quite convenient and readable.
      Unfortunately these cases hit the super-slow-path of the Function#apply
      machinery in V8 currently, because Function#apply doesn't have any
      fast-path for TypedArrays.
      
      This CL adds a proper fast-path to CreateListFromArrayLike to the
      ElementsAccessor, which can be used as long as the typed array that's
      passed wasn't neutered. With this fast-path in place, the performance on
      the micro-benchmark mentioned in the issue improves from
      
        stringFromCharCode: 6386 ms.
        stringFromCodePoint: 8752 ms.
      
      to
      
        stringFromCharCode: 1932 ms.
        stringFromCodePoint: 4262 ms.
      
      which corresponds to a 2.0x-3.3x improvement.
      
      Bug: v8:2435
      Change-Id: I4d39666e53644b11d5856982b005928e26f296fe
      Reviewed-on: https://chromium-review.googlesource.com/657405Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47936}
      f31bae03
  29. 05 Sep, 2017 1 commit
    • Franziska Hinkelmann's avatar
      [api] Use query interceptor in Object.keys(). · 43bb2778
      Franziska Hinkelmann authored
      The V8 API provides interceptors. They are not part of the
      EcmaScript specification. But their behavior should be consistent.
      For example, when an EnumeratorInterceptor is defined, Object.keys(),
      Object.entries(), and Object.values() should all have the
      same number of entries.
      
      This CL creates consistent behavior among these
      functions. If a QueryCallback is present, it is used to
      filter the result from the EnumeratorCallback for
      enumerable properties.
      
      Bug: v8:6627
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I4f4271ddeb99a5e85918148c5033923c149b9468
      Reviewed-on: https://chromium-review.googlesource.com/649786Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47831}
      43bb2778
  30. 22 Aug, 2017 1 commit
  31. 18 Aug, 2017 1 commit
    • Franziska Hinkelmann's avatar
      [api] Use query interceptor in Object.keys(). · b6059a67
      Franziska Hinkelmann authored
      The V8 API provides interceptors. They are not part of the
      EcmaScript specification. But their behavior should be consistent.
      For example, when an EnumeratorInterceptor is defined, Object.keys(),
      Object.entries(), and Object.values() should all have the
      same number of entries.
      
      This CL creates consistent behavior among these
      functions. If a QueryCallback is present, it is used to
      filter the result from the EnumeratorCallback for
      enumerable properties.
      
      Bug: v8:6627
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Ie51e69bb77099d9fafc4b1ea02671eced610edba
      Reviewed-on: https://chromium-review.googlesource.com/609068Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47442}
      b6059a67
  32. 06 Jul, 2017 1 commit
  33. 23 Jun, 2017 1 commit
  34. 19 Apr, 2017 1 commit
    • Peter Marshall's avatar
      [builtins] Use the ElementsAccessor to copy TypedArrays. · 356e9246
      Peter Marshall authored
      This includes a fastpath in the ElementsAccessor for the source
      array being a JSArray with FastSmi or FastDouble packed kinds. This
      is probably a pretty common usage, where an array is passed in as
      a way of initializing the TypedArray at creation (as there is not other
      syntax to do this). e.g. new Float64Array([1.0, 1.0, 1.0]) for some
      sort of vector application.
      
      BUG= v8:5977
      
      Change-Id: Ice4ad9fc29f56b1c4b0b30736a1330efdc289003
      Reviewed-on: https://chromium-review.googlesource.com/465126Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44722}
      356e9246
  35. 12 Apr, 2017 2 commits