1. 18 Oct, 2018 1 commit
  2. 15 Oct, 2018 1 commit
  3. 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
  4. 01 Oct, 2018 1 commit
  5. 26 Sep, 2018 1 commit
  6. 19 Sep, 2018 1 commit
  7. 17 Sep, 2018 1 commit
  8. 08 Aug, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Optimistic slack tracking completion. · bba36e19
      Jaroslav Sevcik authored
      The idea is to compute the slack before compilation start. Then
      we check that the slack tracking decision is the same at the end
      of compilation. If it is, we just commit to that slack tracking
      (by calling function->CompleteInobjectSlackTrackingIfActive).
      If the slack tracking decision changed, we will retry the compilation.
      
      This has several pieces:
      - Expose computation of slack and instance size from the object model.
      - Add compilation dependency on the slack tracking result.
      - Change create lowering to use the dependency.
      - Fix array creation to use the slack tracking result's instance
        size.
      
      Bug: v8:7790
      Change-Id: Id975300cfd6c1786733cd7cbf55cc507c05738b2
      Reviewed-on: https://chromium-review.googlesource.com/1164957Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54982}
      bba36e19
  9. 23 Jul, 2018 1 commit
  10. 18 Jul, 2018 1 commit
  11. 06 Jul, 2018 1 commit
  12. 02 Jul, 2018 1 commit
  13. 27 Jun, 2018 1 commit
  14. 25 Jun, 2018 1 commit
  15. 20 Jun, 2018 1 commit
  16. 07 Jun, 2018 1 commit
  17. 19 Apr, 2018 1 commit
  18. 04 Apr, 2018 1 commit
  19. 05 Mar, 2018 1 commit
    • Benedikt Meurer's avatar
      [es2015] Refactor the JSArrayIterator. · 06ee127b
      Benedikt Meurer authored
      This changes the JSArrayIterator to always have only a single instance
      type, instead of the zoo of instance types that we had before, and
      which became less useful with the specification update to when "next"
      is loaded from the iterator now. This greatly simplifies the baseline
      implementation of the array iterator, which now only looks at the
      iterated object during %ArrayIteratorPrototype%.next invocations.
      
      In TurboFan we introduce a new JSCreateArrayIterator operator, that
      holds the IterationKind and get's the iterated object as input. When
      optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
      check whether the receiver is a JSCreateArrayIterator, and if so,
      we try to infer maps for the iterated object from there. If we find
      any, we speculatively assume that these won't have changed during
      iteration (as we did before with the previous approach), and generate
      fast code for both JSArray and JSTypedArray iteration.
      
      Drive-by-fix: Drop the fast_array_iteration protector, it's not
      necessary anymore since we have the deoptimization guard bit in
      the JSCallReducer now.
      
      This addresses the performance cliff noticed in webpack 4. The minimal
      repro on the tracking bug goes from
      
        console.timeEnd: mono, 124.773000
        console.timeEnd: poly, 670.353000
      
      to
      
        console.timeEnd: mono, 118.709000
        console.timeEnd: poly, 141.393000
      
      so that's a 4.7x improvement.
      
      Also make presubmit happy by adding the missing #undef's.
      
      Bug: v8:7510, v7:7514
      Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
      Reviewed-on: https://chromium-review.googlesource.com/946098Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51725}
      06ee127b
  20. 23 Feb, 2018 3 commits
  21. 24 Jan, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Reduce promise creation overhead in async functions · 18d02b4f
      Benedikt Meurer authored
      This adds a new operator JSCreatePromise, which currently allocates
      a native JSPromise instance and initializes it to pending state.
      
      In addition to that we introduce a new PromiseHookProtector, which
      get's invalidated the first time someone enables the debugger or
      installs a PromiseHook (via async_hooks for example). As long as
      the protector is intact we lower AsyncFunctionPromiseCreate to
      JSCreatePromise and AsyncFunctionPromiseRelease to a no-op in
      optimized code.
      
      This yields a speedup of roughly 33% on the benchmark mentioned
      in the bug.
      
      Bug: v8:7271, v8:7253
      Change-Id: Ib5d219f2b6e052a7cc5e6ed5aa66dd3c8885a859
      Reviewed-on: https://chromium-review.googlesource.com/883124
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50849}
      18d02b4f
  22. 17 Oct, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Inline Function#bind in more cases. · 594803c9
      Benedikt Meurer authored
      So far the inlining of Function#bind into TurboFan optimized code was
      limited to cases where TurboFan could infer the constant JSFunction that
      was bound. However we can easily extend that to cover JSBoundFunction as
      well, and obviously also take the LOAD_IC feedback if we don't have a
      known JSFunction or JSBoundFunction.
      
      This adds a new operator JSCreateBoundFunction that contains the logic
      for the creation of the bound function object and the arguments.
      
      On the micro-benchmarks we go from
      
        functionBindParameter0: 1239 ms.
        functionBindConstant0: 478 ms.
        functionBindBoundConstant0: 1256 ms.
        functionBindParameter1: 1278 ms.
        functionBindConstant1: 475 ms.
        functionBindBoundConstant1: 1253 ms.
        functionBindParameter2: 1431 ms.
        functionBindConstant2: 616 ms.
        functionBindBoundConstant2: 1437 ms.
      
      to
      
        functionBindParameter0: 462 ms.
        functionBindConstant0: 485 ms.
        functionBindBoundConstant0: 474 ms.
        functionBindParameter1: 478 ms.
        functionBindConstant1: 474 ms.
        functionBindBoundConstant1: 474 ms.
        functionBindParameter2: 617 ms.
        functionBindConstant2: 614 ms.
        functionBindBoundConstant2: 616 ms.
      
      which is a ~2.5x improvement. On the jshint benchmark in the
      web-tooling-benchmark we observe a 2-3% improvement, which corresponds
      to the time we had seen it running in the generic version.
      
      Bug: v8:6936, v8:6946
      Change-Id: I940d13220ff35ae602dbaa33349ba4bbe0c9a9d3
      Reviewed-on: https://chromium-review.googlesource.com/723080Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48639}
      594803c9
    • Marja Hölttä's avatar
      [objects.h splitting] Move JSArray, JSRegExp + related classes. · 490fabb4
      Marja Hölttä authored
      BUG=v8:5402,v8:6921
      
      Change-Id: Iab2509554718a6beca73217f80cafedf650bd066
      Reviewed-on: https://chromium-review.googlesource.com/718741Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48629}
      490fabb4
  23. 06 Oct, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Add support to inline new Array(n) calls. · 34de39bf
      Benedikt Meurer authored
      Make calls like
      
        new Array(n)
        new A(n)
      
      (where A is a subclass of Array) inlinable into TurboFan. We do this by
      speculatively checking that n is an unsigned integer that is not greater
      than JSArray::kInitialMaxFastElementArray, and then lowering the backing
      store allocation to a builtin call. The speculative optimization is
      either protected by the AllocationSite for the Array constructor
      invocation (if we have one), or by a newly introduced global protector
      cell that is used for Array constructor invocations that don't have an
      AllocationSite, i.e. the ones from Array#map, Array#filter, or from
      subclasses of Array.
      
      Next step will be to implement the backing store allocations inline in
      TurboFan, but that requires Loop support in the GraphAssembler, so it's
      done as a separate CL. This should further boost the performance.
      
      This boosts the ARES6 ML benchmark by up to 8% on the steady state,
      and also improves monomorphic Array#map calls by around 20-25% on the
      initial setup.
      
      Bug: v8:6399
      Tbr: ulan@chromium.org
      Change-Id: I7c8bdecf7c814ce52db6ee3051c3206a4f7d4bb6
      Reviewed-on: https://chromium-review.googlesource.com/704639
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48348}
      34de39bf
    • Benedikt Meurer's avatar
      [turbofan] Refactor the JSCreateArray lowering to support more cases. · 279a83e4
      Benedikt Meurer authored
      Array (subclass) constructor calls with 0 parameters are now properly
      turned into inline allocations, also Array (subclass) constructor calls
      with exactly one parameter, which is either known to not be a Number
      or which is a known integer in the valid loop unrolling range.
      
      Also refactor the general JSCreateArray lowering logic to properly
      support Array subclasses, i.e. deal with inobject properties and
      initial maps correctly.
      
      This boosts performance of those cases significantly (and will allow
      us to reduce the complexity of the Array constructor significantly
      long-term). For example the simple case
      
        new Array("a", "b", "c", "d", "e", "f", "g")
      
      is now around 10x faster than before.
      
      Bug: v8:6399
      Change-Id: I70661971398524ee0c6a349ee559b98a962a6266
      Reviewed-on: https://chromium-review.googlesource.com/703134
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48325}
      279a83e4
  24. 28 Sep, 2017 1 commit
    • Michael Starzinger's avatar
      Reland "[turbofan] Implement lowering of {JSCreateClosure}." · ac475636
      Michael Starzinger authored
      This is a reland of 9d3c4b4b
      Original change's description:
      > [turbofan] Implement lowering of {JSCreateClosure}.
      > 
      > This adds support for inline allocation of {JSFunction} objects as part
      > of closures instantiation for {JSCreateClosure} nodes. The lowering is
      > limited to instantiation sites which have already seen more than one
      > previous instantiation, this avoids the need to increment the respective
      > counter.
      > 
      > R=jarin@chromium.org
      > 
      > Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
      > Reviewed-on: https://chromium-review.googlesource.com/594287
      > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48176}
      
      Change-Id: I3ec3880bea89798a34a3878e6122b95db1014151
      Reviewed-on: https://chromium-review.googlesource.com/686834Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48198}
      ac475636
  25. 27 Sep, 2017 2 commits
    • Michael Starzinger's avatar
      Revert "[turbofan] Implement lowering of {JSCreateClosure}." · 9e618c72
      Michael Starzinger authored
      This reverts commit 9d3c4b4b.
      
      Reason for revert: Breaks cctest/test-debug/NoBreakWhenBootstrapping in no-snap mode.
      
      Original change's description:
      > [turbofan] Implement lowering of {JSCreateClosure}.
      > 
      > This adds support for inline allocation of {JSFunction} objects as part
      > of closures instantiation for {JSCreateClosure} nodes. The lowering is
      > limited to instantiation sites which have already seen more than one
      > previous instantiation, this avoids the need to increment the respective
      > counter.
      > 
      > R=​jarin@chromium.org
      > 
      > Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
      > Reviewed-on: https://chromium-review.googlesource.com/594287
      > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48176}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org
      
      Change-Id: Id52281f6a3c0b7c2603053ecf002777d5b0d6f1f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/686534Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48178}
      9e618c72
    • Michael Starzinger's avatar
      [turbofan] Implement lowering of {JSCreateClosure}. · 9d3c4b4b
      Michael Starzinger authored
      This adds support for inline allocation of {JSFunction} objects as part
      of closures instantiation for {JSCreateClosure} nodes. The lowering is
      limited to instantiation sites which have already seen more than one
      previous instantiation, this avoids the need to increment the respective
      counter.
      
      R=jarin@chromium.org
      
      Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
      Reviewed-on: https://chromium-review.googlesource.com/594287
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48176}
      9d3c4b4b
  26. 25 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored
      When inlining based on SharedFunctionInfo rather than based on concrete
      JSFunction, we weren't able to properly optimize array, object and
      regexp literals inside the inlinee, because we didn't know the concrete
      FeedbackVector for the inlinee inside JSCreateLowering. This was because
      JSCreateLowering wasn't properly updated after the literals moved to the
      FeedbackVector. Now with this CL we also have the VectorSlotPair on the
      literal creation operators, just like we do for property accesses and
      calls, and are thus able to always access the appropriate FeedbackVector
      and optimize the literal creation.
      
      The impact is illustrated by the micro-benchmark on the tracking bug,
      which goes from
      
        createEmptyArrayLiteral: 1846 ms.
        createShallowArrayLiteral: 1868 ms.
        createShallowObjectLiteral: 2246 ms.
      
      to
      
        createEmptyArrayLiteral: 1175 ms.
        createShallowArrayLiteral: 1187 ms.
        createShallowObjectLiteral: 1195 ms.
      
      with this CL, so up to 2x faster now.
      
      Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
      and cleanup the names of the other builtins to be consistent with the
      names of the TurboFan operators and Ignition bytecodes.
      
      Bug: v8:6856
      Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
      Reviewed-on: https://chromium-review.googlesource.com/680656
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
  27. 01 Sep, 2017 1 commit
  28. 28 Aug, 2017 1 commit
  29. 22 Aug, 2017 1 commit
  30. 21 Aug, 2017 1 commit
  31. 25 Jul, 2017 1 commit
  32. 20 Jul, 2017 2 commits
  33. 19 Jul, 2017 1 commit
  34. 13 Jul, 2017 1 commit