1. 13 May, 2022 1 commit
  2. 03 Mar, 2022 1 commit
  3. 13 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored
      This unifies and simplifies the way we instrument async functions for
      the purpose of async stack traces and async stepping. It does so while
      retaining the observable behavior on the inspector level (for now).
      
      Previously we'd mark the implicit promise of the async function object
      with the async task ID, and whenever we awaited, we'd copy the async
      task ID to the throwaway promise that is created by the `await`. This
      however made things unnecessarily interesting in the following regards:
      
      1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
      `AsyncFunctionFinished` events, coming from the throwaway promises,
      while the implicit promise is "done". This is especially confusing
      with rejection propagation and requires very complex stepping logic
      for async functions (after this CL it'll be possible to unify and
      simplify the stepping logic).
      2. We have to thread through the "can suspend" information from the
      Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
      to the async function instrumentation to decide whether to cancel the
      pending task when the async function finishes.
      
      This CL changes the instrumentation to only happen (non recurringly) for
      the throwaway promises allocated upon `await`. This solves both problems
      mentioned above, and works because upon the first `await` the stack
      captured for the throwaway promise will include the synchronous part as
      expected, while upon later `await`s the synchronous part will be empty
      and the asynchronous part will be the stack captured for the previous
      throwaway promise (and the V8Debugger automatically short circuits
      stacks with empty synchronous part).
      
      Bug: chromium:1280519, chromium:1277451, chromium:1246867
      Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
  4. 17 Jun, 2021 2 commits
  5. 23 Apr, 2021 1 commit
  6. 25 Sep, 2020 1 commit
  7. 21 May, 2019 1 commit
  8. 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
  9. 23 Apr, 2019 1 commit
  10. 04 Apr, 2019 1 commit
  11. 11 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Introduce dedicated JSAsyncFunctionObject. · a63987a4
      Benedikt Meurer authored
      This JSAsyncFunctionObject represents the implicit generator object
      inside of async functions, and also holds the outer promise for the
      async functions. This in turn allows us to get rid of the .promise
      in the Parser / BytecodeGenerator completely, and will make it
      possible to build zero-cost async stack traces independent of the
      concrete synchronous part of the stack frame (which currently breaks
      in Node.js).
      
      In the bytecode all the async function operations now take this new
      JSAsyncFunctionObject instead of passing both the .generator_object
      and the .promise, which further simplifies and shrinks the bytecode.
      It also reduces the size of async function frames, potentially making
      the suspend/resume cheaper.
      
      This also changes `await` to use intrinsics instead of calling to
      special JSFunctions on the native context, and thus reduces the size of
      the native contexts.
      
      Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator
      to TurboFan.
      
      Bug: v8:7253, v8:7522
      Change-Id: I2305302285156aa1f71328ecac70377abdd92c80
      Ref: nodejs/node#11865
      Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
      Reviewed-on: https://chromium-review.googlesource.com/c/1273049
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56554}
      a63987a4
  12. 10 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Improve async function handling. · 0038e5f0
      Benedikt Meurer authored
      This change introduces new intrinsics used to desugar async functions
      in the Parser and the BytecodeGenerator, namely we introduce a new
      %_AsyncFunctionEnter intrinsic that constructs the generator object
      for the async function (and in the future will also create the outer
      promise for the async function). This generator object is internal
      and never escapes to user code, plus since async functions don't have
      a "prototype" property, we can just a single map here instead of tracking
      the prototype/initial_map on every async function. This saves one word
      per async function plus one initial_map per async function that was
      invoked at least once.
      
      We also introduce two new intrinsics %_AsyncFunctionReject, which
      rejects the outer promise with the caught exception, and another
      %_AsyncFunctionResolve, which resolves the outer promise with the
      right hand side of the `return` statement. These functions also perform
      the DevTools part of the job (aka popping from the promise stack and
      sending the debug event). This allows us to get rid of the implicit
      try-finally from async functions completely; because the finally
      block only called to the %AsyncFunctionPromiseRelease builtin, which
      was used to inform DevTools.
      
      In essence we now turn an async function like
      
      ```js
      async function f(x) { return await bar(x); }
      ```
      
      into something like this (in Parser and BytecodeGenerator respectively):
      
      ```
      function f(x) {
        .generator_object = %_AsyncFunctionEnter(.closure, this);
        .promise = %AsyncFunctionCreatePromise();
        try {
          .tmp = await bar(x);
          return %_AsyncFunctionResolve(.promise, .tmp);
        } catch (e) {
          return %_AsyncFunctionReject(.promise, e);
        }
      }
      ```
      
      Overall the bytecode for async functions gets significantly shorter
      already (and will get even shorter once we put the outer promise into
      the async function generator object). For example the bytecode for a
      simple async function
      
      ```js
      async function f(x) { return await x; }
      ```
      
      goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
      is in particular due to the simplification around the try-finally
      removal.
      
      Overall this seems to improve the doxbee-async-es2017-native test by
      around 2-3%. On the test case mentioned in v8:8276 we go from
      1124ms to 441ms, which corresponds to a 60% reduction in total
      execution time!
      
      Tbr: marja@chromium.org
      Bug: v8:7253, v8:7522, v8:8276
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
      Reviewed-on: https://chromium-review.googlesource.com/c/1269041
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56502}
      0038e5f0
  13. 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
  14. 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
  15. 25 Sep, 2018 1 commit
  16. 20 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove a lot of dead intrinsics/runtime functions. · 44c24bf8
      Benedikt Meurer authored
      The following runtime functions (and their intrinsic counter parts) are
      completely unused/obsolete by now
      
        - %ToInteger
        - %GeneratorGetInputOrDebugPos
      
      and in addition the intrinsics for %_ToNumber and %_IsJSProxy are also
      dead (according to code coverage and manual verification), so drop them
      as well (their runtime function counterparts are still somewhat used).
      
      Bug: v8:8015
      Change-Id: I60d53762dd9717fb43de38cb490b46676c467212
      Reviewed-on: https://chromium-review.googlesource.com/1235923Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56076}
      44c24bf8
  17. 21 Aug, 2018 1 commit
  18. 09 Aug, 2018 1 commit
  19. 08 Aug, 2018 1 commit
  20. 07 Aug, 2018 1 commit
  21. 03 Jun, 2018 1 commit
  22. 14 May, 2018 1 commit
  23. 20 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Turn await closures into intrinsics. · d97bb317
      Benedikt Meurer authored
      There's no need to have the AsyncFunctionAwait/AsyncGeneratorAwait
      operations as separate closures that are called via JavaScript calling
      convention, but instead we can just have them as intrinsics (with the
      goal to eventually turn them into IC stubs).
      
      Drive-by-fix: Tail call to the ResumeGenerator builtin when resuming
      an async function. The earlier restrictions no only apply with the new
      machinery.
      
      Bug: v8:7253
      Change-Id: I0c4d04dae15b4211158fc07151adafda69d4faec
      Reviewed-on: https://chromium-review.googlesource.com/924703Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51382}
      d97bb317
  24. 15 Feb, 2018 1 commit
  25. 13 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Refactor the promise resolution and rejection logic. · c0412961
      Benedikt Meurer authored
      This introduces dedicated builtins
      
        - FulfillPromise,
        - RejectPromise, and
        - ResolvePromise,
      
      which perform the corresponding operations from the language
      specification, and removes the redundant entry points and the
      excessive inlining of these operations into other builtins. We
      also add the same logic on the C++ side, so that we don't need
      to go into JavaScript land when resolving/rejecting from the
      API.
      
      The C++ side has a complete implementation, including full support
      for the debugger and the current PromiseHook machinery. This is to
      avoid constantly crossing the boundary for those cases, and to also
      simplify the CSA side (and soon the TurboFan side), where we only
      do the fast-path and bail out to the runtime for the general handling.
      
      On top of this we introduce %_RejectPromise and %_ResolvePromise,
      which are entry points used by the bytecode and parser desugarings
      for async functions, and also used by the V8 Extras API. Thanks to
      this we can uniformly optimize these in TurboFan, where we have
      corresponding operators JSRejectPromise and JSResolvePromise, which
      currently just call into the builtins, but middle-term can be further
      optimized, i.e. to skip the "then" lookup for JSResolvePromise when
      we know something about the resolution.
      
      In TurboFan we can also already inline the default PromiseCapability
      [[Reject]] and [[Resolve]] functions, although this is not as effective
      as it can be right now, until we have inlining support for the Promise
      constructor (being worked on by petermarshall@ right now) and/or SFI
      based CALL_IC feedback.
      
      Overall this change is meant as a refactoring without significant
      performance impact anywhere; it seems to improve performance of
      simple async functions a bit, but otherwise is neutral.
      
      Bug: v8:7253
      Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
      Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51260}
      c0412961
  26. 02 Feb, 2018 1 commit
  27. 24 Jan, 2018 1 commit
  28. 20 Oct, 2017 1 commit
  29. 18 Oct, 2017 1 commit
  30. 08 Aug, 2017 1 commit
  31. 14 Jul, 2017 1 commit
    • Caitlin Potter's avatar
      [generators] remove SuspendFlags enum and related code · 53553f5d
      Caitlin Potter authored
      SuspendFlags was originally used by the suspend operation to determine
      which field to record the bytecode offset of a suspended generator, and
      the value the generator was resumed with. For async generators, await
      operations would use a separate field, in order to preserve the previous
      yield input value. This was important to ensure `function.sent`
      continued to function correctly.
      
      As function.sent is being retired, this allows the removal of support
      for that. Given that this was the only real need for SuspendFlags in the
      first place (with other uses tacked on as a hack), this involves several
      other changes as well:
      
      - Modification of MacroAssembler AssertGeneratorObject. No longer
        accepts a SuspendFlags parameter to determine which type of check to
        perform.
      - Removal of `flags` operand from SuspendGenerator bytecode, and the
        GeneratorStore js-operator.
      - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
      - Removal of Runtime functions, interpreter intrinsics and
        AccessBuilders associated with the [[await_input_or_debug_pos]] field
        in JSAsyncGeneratorObject, as this field no longer exists.
      - Addition of a new `Yield` AST node (subclass of Suspend) in order to
        prevent the need for the other SuspendFlag values.
      
      BUG=v8:5855
      TBR=bmeurer@chromium.org
      
      Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
      Reviewed-on: https://chromium-review.googlesource.com/570485
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46683}
      53553f5d
  32. 10 Jul, 2017 2 commits
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3b84cbfe
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      TBR=jgruber@chromium.org
      
      Bug: v8:6344, v8:6571, chromium:740122
      Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
      Reviewed-on: https://chromium-review.googlesource.com/563626
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46497}
      3b84cbfe
    • Michael Achenbach's avatar
      Revert "[builtins] Port Map and Set iterators to CodeStubAssembler." · 5a6e24e9
      Michael Achenbach authored
      This reverts commit 3f22832b.
      
      Reason for revert: Layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16849
      
      Original change's description:
      > [builtins] Port Map and Set iterators to CodeStubAssembler.
      > 
      > This is the next step towards faster Map and Set iteration. It
      > introduces the appropriate instance types for Map and Set
      > iterators (following the pattern for Array iterators) and migrates
      > the following builtins to the CodeStubAssembler:
      > 
      >   - Set.prototype.entries
      >   - Set.prototype.values
      >   - Map.prototype.entries
      >   - Map.prototype.keys
      >   - Map.prototype.values
      >   - %SetIteratorPrototype%.next
      >   - %MapIteratorPrototype%.next
      > 
      > This already provides a significant performance boost for regular
      > for-of iteration of Sets and Maps, by a factor of 5-10 depending
      > on the input. The final step will be to inline some fast-paths
      > into TurboFan.
      > 
      > Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      > intrinsics and runtime functions.
      > 
      > Bug: v8:6571, chromium:740122
      > Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      > Reviewed-on: https://chromium-review.googlesource.com/563399
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46492}
      
      TBR=jgruber@chromium.org,bmeurer@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iadb48d72e3b85ec8ad880e50ab7912c5502caf07
      Reviewed-on: https://chromium-review.googlesource.com/564419Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46495}
      5a6e24e9
  33. 08 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Port Map and Set iterators to CodeStubAssembler. · 3f22832b
      Benedikt Meurer authored
      This is the next step towards faster Map and Set iteration. It
      introduces the appropriate instance types for Map and Set
      iterators (following the pattern for Array iterators) and migrates
      the following builtins to the CodeStubAssembler:
      
        - Set.prototype.entries
        - Set.prototype.values
        - Map.prototype.entries
        - Map.prototype.keys
        - Map.prototype.values
        - %SetIteratorPrototype%.next
        - %MapIteratorPrototype%.next
      
      This already provides a significant performance boost for regular
      for-of iteration of Sets and Maps, by a factor of 5-10 depending
      on the input. The final step will be to inline some fast-paths
      into TurboFan.
      
      Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
      intrinsics and runtime functions.
      
      Bug: v8:6571, chromium:740122
      Change-Id: Iad7a7dec643d8f8b5799327f89a351108ae856bf
      Reviewed-on: https://chromium-review.googlesource.com/563399
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46492}
      3f22832b
  34. 19 May, 2017 2 commits
  35. 11 May, 2017 1 commit
  36. 10 May, 2017 2 commits