1. 05 Nov, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] qualified access to CSA assemblers · 23b48920
      Tobias Tebbi authored
      No longer use inheritance to associate Torque-generated assemblers
      with corresponding CSA subclasses. Instead, all references to CSA
      and CSA-derived assemblers are now explicitly qualified, by generating
      a short-lived assembler instance in-place. As a consequence, Torque
      files have to mention the assembler external macros live in.
      The CodeStubAssembler is the default for this and can be omitted.
      As a drive-by cleanup, also distinguish between names that are emitted
      in C++ and names that are intended to be read in error messages. This
      is relevant for generic instantiations, where the generated names are
      rather unreadably mangled.
      
      As a follow-up, it will be easy to allow for qualified access to
      different modules, thus implementing full namespace semantics for
      modules.
      
      Bug: v8:7793
      Change-Id: Ie6f1b6b549b510fb49be2442393d898d5f130950
      Reviewed-on: https://chromium-review.googlesource.com/c/1309636
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57235}
      23b48920
  2. 31 Oct, 2018 1 commit
  3. 26 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Add Promise.all() support to --async-stack-traces. · 6f39ab89
      Benedikt Meurer authored
      This adds support for Promise.all() to --async-stack-traces (also at
      zero cost, since we can derive the relevant information from the resolve
      element closure and context). In case of `Promise.all(a)` the stack
      trace even tells you which element of `a` is responsible, for example
      
      ```js
      async function fine() {}
      async function thrower() { await fine(); throw new Error(); }
      async function test() { await Promise.all([fine(), thrower()]); }
      ```
      
      will generate the following stack trace
      
      ```
      Error
          at thrower (something.js:1:9)
          at async Promise.all (index 1)
          at async test (something.js:3:3)
      ```
      
      so it not only shows the async Promise.all() frames, but even tells the
      user exactly that the second element of `[fine(), thrower()]` is the
      relevant one.
      
      Bug: v8:7522
      Change-Id: I279a845888e06053cf0e3c9338ab71caabaabf45
      Reviewed-on: https://chromium-review.googlesource.com/c/1299248Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57023}
      6f39ab89
  4. 22 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [promises] Add fast-path for native promises to Promise.all. · 50f713c9
      Benedikt Meurer authored
      This CL introduces a new fast-path for `Promise.all(a)` for the case
      that elements in `a` are native promises, and the Promise.prototype
      and Promise function itself are intact. If so, we can skip the lookups
      of "resolve" on Promise and "then" on the result of invoking "resolve",
      which are both quite expensive, and we can instead directly call the
      PerformPromiseThen() operation on the element of `a`.
      
      In addition to that we don't need to create and chain a result promise,
      since this is only used when either async_hooks or DevTools are enabled.
      Otherwise it's a "throwaway promise" only used to satisfy the operation
      parameter signature (see https://github.com/tc39/ecma262/pull/1146).
      
      This results in a significant performance improvement on `Promise.all()`
      heavy code. For example the parallel-promises-es2015-native test goes
      from around 84ms to roughly 68ms, which is almost a 20% improvement.
      
      Bug: v8:7253
      Ref: tc39/ecma262#1146
      Change-Id: Iab9c57edb26d13a467b0653fd8de6149c382efc6
      Reviewed-on: https://chromium-review.googlesource.com/c/1293374Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56858}
      50f713c9
  5. 20 Sep, 2018 1 commit
  6. 09 Jul, 2018 1 commit
  7. 17 May, 2018 1 commit
  8. 14 May, 2018 1 commit
  9. 22 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Reduce resolve element closure overhead in Promise.all. · d8658177
      Benedikt Meurer authored
      In Promise.all we used to allocate a fresh closure plus a fresh context
      for each individual element, which is quite a lot of overhead, especially
      since this could be shared in a single context for all elements. The only
      bit of information that is needed for each resolve element closure is the
      index under which to store the resulting value. With this change we move
      this index to the "identity hash" field of the JSFunction, which doesn't
      care about the concrete value anyways, as long as it's not zero (the "no
      hash" sentinel), and share the rest of the fields in a single outer
      context for all resolve element closures.
      
      This limits the maximum number of elements for Promise.all to 2^21 for
      now, but that should be fine. Shall we ever see the need for more than
      this, we can add machinery to overflow to separate context for indices
      larger than 2^21.
      
      This significantly reduces the overhead due to Promise.all on the
      parallel-async-es2017-native test, with execution time dropping from
      around 148ms to 133ms, so overall a steady 10% improvement on this
      benchmark.
      
      Bug: v8:7253
      Change-Id: I1092da771c4919f3db7129d2b0a244fc26a7b144
      Reviewed-on: https://chromium-review.googlesource.com/973283Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52134}
      d8658177
  10. 08 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Add fast-path for the Promise.resolve lookup. · e122fc45
      Benedikt Meurer authored
      This adds a global protector to guard the lookup of "resolve" on the
      %Promise% intrinsic object (the initial Promise constructor), making
      sure that Promise.resolve yields the initial builtin method. We use
      this protector to avoid the lookup of "resolve" all the time inside
      of Promise.all and Promise.race, when called with constructor being
      the %Promise% intrinsic object.
      
      This improves the performance on the parallel-async-es2017-native
      benchmark by roughly 2-3%.
      
      Bug: v8:7253
      Change-Id: Ida93b88afbaeae61f17be4cd30ea6a78b4267cea
      Reviewed-on: https://chromium-review.googlesource.com/955564Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51810}
      e122fc45
  11. 26 Feb, 2018 1 commit
  12. 16 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [async-await] Eliminate throwaway promise in async functions. · a840f1f8
      Benedikt Meurer authored
      The ES2017 specification contains a so-called "throwaway" promise that
      is used to specify the behavior of await in terms of PerformPromiseThen,
      but it's actually not necessary and never exposed to user code. In
      addition to that, hooking up the promise in await required a context (to
      refer to the generator object) and two closures for the reject/fulfill
      handling, which would resume the generator corresponding to the async
      function. That meant, we had to allocate 4 additional objects for every
      await.
      
      Instead of using a JSPromise plus the callbacks, this CL adds logic to
      allow PromiseReaction and PromiseReactionJobTask to carry arbitrary
      payloads and Code handlers. We use this for await to avoid the
      additional 4 objects mentioned above, and instead just have simple Code
      handlers that resume the generator (for the async function), either by
      throwing (in case of a rejection) or by resuming normally (in case of
      fulfillment).
      
      For this to work properly the JSGeneratorObject has to have a link to
      the outer promise returned by the async function, so that the catch
      prediction can still figure out what to do in case of promise rejection.
      This is done by adding a new generator_outer_promise_symbol when the
      debugger is active, which refers from the generator to the outer
      promise.
      
      With this change the doxbee-async-es2017-native test goes from around
      100.54ms to around 82.45ms, which corresponds to a ~18% reduction in
      execution time.
      
      Bug: v8:7253
      Change-Id: Iae25b3300bac351c3417be5ae687eff469b0e61f
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/924069Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51334}
      a840f1f8
  13. 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
  14. 08 Feb, 2018 1 commit
    • Adam Klein's avatar
      Revert "[builtins] Mega-revert to address the Dev blocker in crbug.com/808911." · 3916401e
      Adam Klein authored
      This reverts commit 14108f4c.
      
      Reason for revert: Not the culprit for Canary microtask crashes
      
      Original change's description:
      > [builtins] Mega-revert to address the Dev blocker in crbug.com/808911.
      > 
      > - Revert "[builtins] Save one word in contexts for Promise.all."
      >   This reverts commit 7632da06.
      > - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
      >   This reverts commit d4f072ce.
      > - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
      >   This reverts commit 6703dacd.
      > - Revert "[debugger] Properly deal with settled promises in catch prediction."
      >   This reverts commit 40dd0658.
      > - Revert "[builtins] Widen the fast-path for Promise builtins."
      >   This reverts commit db0556b7.
      > - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
      >   This reverts commit a582199c.
      > - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
      >   This reverts commit 6bf88852.
      > - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
      >   This reverts commit 313b490d.
      > - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
      >   This reverts commit f7bd6a2f.
      > - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
      >   This reverts commit b23b098f.
      > - Revert "[promise] Remove incorrect fast path"
      >   This reverts commit 0f6eafe8.
      > - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
      >   This reverts commit 8a677a28.
      > - Revert "[builtins] Refactor promises to reduce GC overhead."
      >   This reverts commit 8e7737cb.
      > 
      > Tbr: hpayer@chromium.org
      > Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
      > Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/906991
      > Commit-Queue: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51158}
      
      Change-Id: I09d958cbebd635a325809072a290f2f53df8c5d4
      Tbr: adamk@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
      Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/908988Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51181}
      3916401e
  15. 07 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Mega-revert to address the Dev blocker in crbug.com/808911. · 14108f4c
      Benedikt Meurer authored
      - Revert "[builtins] Save one word in contexts for Promise.all."
        This reverts commit 7632da06.
      - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
        This reverts commit d4f072ce.
      - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
        This reverts commit 6703dacd.
      - Revert "[debugger] Properly deal with settled promises in catch prediction."
        This reverts commit 40dd0658.
      - Revert "[builtins] Widen the fast-path for Promise builtins."
        This reverts commit db0556b7.
      - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
        This reverts commit a582199c.
      - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
        This reverts commit 6bf88852.
      - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
        This reverts commit 313b490d.
      - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
        This reverts commit f7bd6a2f.
      - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
        This reverts commit b23b098f.
      - Revert "[promise] Remove incorrect fast path"
        This reverts commit 0f6eafe8.
      - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
        This reverts commit 8a677a28.
      - Revert "[builtins] Refactor promises to reduce GC overhead."
        This reverts commit 8e7737cb.
      
      Tbr: hpayer@chromium.org
      Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
      Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/906991
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51158}
      14108f4c
  16. 06 Feb, 2018 2 commits
  17. 04 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Widen the fast-path for Promise builtins. · db0556b7
      Benedikt Meurer authored
      This adds a new isolate wide Promise#then protector, which guards the
      "then" lookup for all JSPromise instances whose [[Prototype]] is the
      initial %PromisePrototype%. Thus arbitrary mutations to the
      Promise.prototype (i.e. monkey-patching other methods or installing
      new functions) no longer sent you down the slow-path. Use this protector
      in Promise.prototype.catch and in Promise.resolve.
      
      Drive-by-fix: Restructure the resolve logic a bit and avoid the
      expensive and large SameValue check, which can be turned into a simple
      reference equal, as the promise in there is known to be a JSPromise
      anyways.
      
      Bug: v8:7253
      Change-Id: If68b12c6bc6ca9c4d10552ae84854ebc3b5774f9
      Reviewed-on: https://chromium-review.googlesource.com/899302
      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 avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51085}
      db0556b7
  18. 02 Feb, 2018 3 commits
  19. 01 Feb, 2018 2 commits
  20. 31 Jan, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Refactor promises to reduce GC overhead. · 8e7737cb
      Benedikt Meurer authored
      This implements the ideas outlined in the section "Microtask queue"
      of the exploration document "Promise and async/await performance" (at
      https://goo.gl/WHRar2), except that the microtask queue stays a linear
      FixedArray for now, to avoid running into trouble with the parallel
      scavenger. This way we can already save a significant amount of
      allocations, thereby reducing the GC frequency quite a bit.
      
      All items on the microtask queue are now proper structs that subclass
      Microtask, i.e. we also wrap JSFunction and MicrotaskCallback jobs
      into structs. We also consistently remember the context for every
      microtask (except for MicrotaskCallback where we don't have a
      context), and execute it later in exactly that context (as required
      by the spec anyways for the Promise related jobs). Particularly
      interesting is the PromiseReactionJobTask and its subclasses, since
      they are designed to have the same size as the PromiseReaction. When
      we resolve a JSPromise we just take the existing PromiseReaction
      instances and morph them into PromiseFulfillReactionJobTask or
      PromiseRejectReactionJobTask (depending whether you "Fulfill" or
      "Reject"). That way the JSPromise class is now only 6 words instead
      of 10 words.
      
      Also the PromiseReaction and the reaction tasks can either carry a
      JSPromise (for the fast native case) or a PromiseCapability (for the
      generic case), which means we don't always pay the overhead of having
      to also remember the "deferred resolve" and "deferred reject" handlers
      that are only relevant for the generic case anyways.
      
      It also fixes a spec violation where we called "then" before we actually
      enqueued the PromiseResolveThenableJob, which is observably wrong.
      Calling it later has the advantage that it should be fairly
      straight-forward now to completely avoid it for native Promise
      instances.
      
      This seems to save around 10-20% on the various Promise benchmarks and
      micro-benchmarks. We expect to gain even more as we're now able to
      inline various operations into TurboFan optimized code easily.
      
      Bug: v8:7253
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I893d24ca5bb046974b4f5826a8f6dd22f1210b6a
      Reviewed-on: https://chromium-review.googlesource.com/892819
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50980}
      8e7737cb
  21. 19 Jan, 2018 1 commit
  22. 18 Jan, 2018 2 commits
  23. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org
      TBR=neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
      Reviewed-on: https://chromium-review.googlesource.com/857593
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  24. 09 Jan, 2018 3 commits
    • Benedikt Meurer's avatar
      [builtins] Turn EnqueueMicrotask into a dedicated builtin. · 6ef05c78
      Benedikt Meurer authored
      Inlining the EnqueueMicrotask logic into the various uses blows up the
      snapshot size significantly. So instead of doing that we just turn the
      operation into a dedicated builtin that we call from the various uses.
      This still avoids the runtime function call overhead and maintains the
      fast path without write barriers for the common case of the microtask
      queue fitting into new space.
      
      This also moves back the microtask helper CSA functions to the
      specialized assembler.
      
      Bug: v8:7253, chromium:799563
      Change-Id: I2d24d0e5c01e442c5ad7f5d4373fbc6e94351ac5
      Reviewed-on: https://chromium-review.googlesource.com/856618Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50461}
      6ef05c78
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored
      This reverts commit bf4cc9ee.
      
      Reason for revert: Breaks windows with msvc and linux with gcc
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
      
      Original change's description:
      > [esnext] load `iterator.next` only once at beginning of iteration
      > 
      > https://github.com/tc39/ecma262/pull/988 gained concensus during the
      > september 2017 TC39 meetings. This moves the load of the "next" method
      > to the very beginning of the iteration protocol, rather than during
      > each iteration step.
      > 
      > This impacts:
      > 
      > - yield*
      > - for-of loops
      > - spread arguments
      > - array spreads
      > 
      > In the v8 implementation, this also affects async iteration versions of
      > these things (the sole exception being the Async-From-Sync iterator,
      > which requires a few more changes to work with this, likely done in a
      > followup patch).
      > 
      > This change introduces a new AST node, ResolvedProperty, which can be used
      > as a callee by Call nodes to produce the same bytecode as Property calls,
      > without observably re-loading the property. This is used in several
      > AST-desugarings involving the iteration protocol.
      > 
      > BUG=v8:6861, v8:5699
      > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      > Reviewed-on: https://chromium-review.googlesource.com/687997
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50452}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
      
      Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6861, v8:5699
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      Reviewed-on: https://chromium-review.googlesource.com/687997
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee
  25. 07 Jan, 2018 1 commit
  26. 05 Jan, 2018 1 commit
    • Benedikt Meurer's avatar
      [builtins] Port EnqueueMicrotask to CSA. · 2b4cc835
      Benedikt Meurer authored
      Previously the Promise builtins would always use a runtime function to
      schedule a new microtask, which is unnecessarily expensive. Since the
      runtime function only adds the microtask to a FixedArray (potentially
      growing that array) and increments the number of pending microtasks, it
      is fairly straight-forward to do this in CSA land instead.
      
      This change improves the Bluebird benchmarks by 2-4% on average.
      
      Bug: v8:7253
      Change-Id: I77e96b9e5afbb4bdbe129b6bb289d9905ed581bf
      Reviewed-on: https://chromium-review.googlesource.com/851972
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50372}
      2b4cc835
  27. 07 Nov, 2017 1 commit
  28. 16 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize Reflect.has builtin. · 4213af64
      Benedikt Meurer authored
      Port the baseline version of Reflect.has to the CodeStubAssembler and
      reuse the existing logic for HasProperty (i.e. the HasProperty builtin).
      Also inline the Reflect.has builtin into TurboFan, by adding a check
      on the target in front of a use of the JSHasProperty operator.
      Technically this additional check is not necessary, because the
      JSHasProperty operator already throws if the target is not a JSReceiver,
      but the exception message is confusing then.
      
      This improves the performance of the micro-benchmark from
      
        reflectHasPresent: 337 ms.
        reflectHasAbsent: 472 ms.
      
      to
      
        reflectHasPresent: 121 ms.
        reflectHasAbsent: 216 ms.
      
      which is a nice 2.8x improvement in the best case. It also improves the
      chai test on the web-tooling-benchmark by around 1-2%, which is roughly
      the expected win (since Reflect.has overall accounts for around 3-4%).
      
      Bug: v8:5996, v8:6936, v8:6937
      Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a
      Reviewed-on: https://chromium-review.googlesource.com/720959
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48608}
      4213af64
  29. 07 Sep, 2017 1 commit
  30. 28 Aug, 2017 1 commit
  31. 22 Aug, 2017 1 commit
  32. 08 Jul, 2017 1 commit
    • Caitlin Potter's avatar
      [builtins] port Promise.race to CSA · bba473db
      Caitlin Potter authored
      - Implements the Promise.race algorithm using CodeStubAssembler.
      - Delete src/js/promise.js, which is no longer needed.
      - Migrate Promise constructor from slow to fast object in bootstrapper
        (per v8:5902)
      
      Increases size of snapshot_blob.bin on an x64.release build by 1.27kb.
      
      BUG=v8:5343
      R=gsathya@chromium.org, cbruni@chromium.org
      
      Change-Id: I751e7389bd6ba410109640fcd7960b6021540f2f
      Reviewed-on: https://chromium-review.googlesource.com/535041
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46489}
      bba473db
  33. 30 Jun, 2017 1 commit