1. 15 Nov, 2019 1 commit
  2. 04 Nov, 2019 1 commit
    • Nico Hartmann's avatar
      Preserve feedback and speculation mode for JSCall · 149e4935
      Nico Hartmann authored
      Changing the target of JSCall nodes (e.g. while lowering higher order calls)
      now preserves feedback and speculation mode to allow further (speculative)
      optimizations. A flag is introduced to mark feedback unrelated to the call
      target after such a transformation. This flag is used to prevent access to
      the feedback without the need to invalidate it.
      
      Bug: v8:9702
      Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64733}
      149e4935
  3. 30 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Optionally apply an offset to stack checks" · b875f466
      Jakob Gruber authored
      This is a reland of 4a16305b
      
      The original CL adjust only one part of the stack check, namely the
      comparison of the stack pointer against the stack limit in generated code.
      There is a second part: Runtime::kStackGuard repeats this check to
      distinguish between a stack overflow and an interrupt request.
      
      This second part in runtime must apply the offset just like in generated
      code. It is implemented in this reland by the StackCheckOffset operator
      and a new StackGuardWithGap runtime function.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      >
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      >
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      >
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      >
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      >
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      Bug: v8:9534, chromium:1000887
      Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64634}
      b875f466
  4. 22 Oct, 2019 3 commits
    • Victor Gomes's avatar
      Reland x3 "[runtime] Remove extension slots from context objects" · dbbdd0ec
      Victor Gomes authored
      Original change's description:
      > [runtime] Remove extension slots from context objects
      >
      > Context objects have an extension slot, which contains further
      > additional data that depends on the type of the context.
      >
      > This CL removes the extension slot from contexts that don't need
      > them, hence reducing memory.
      >
      > The following contexts will still have an extension slot: native,
      > module, await, block and with contexts. See objects/contexts.h for
      > what the slot is used for.
      > The following contexts will not have an extension slot anymore (they
      > were not used before): script, catch and builtin contexts.
      > Eval and function contexts only have the extension slot if they
      > contain a sloppy eval.
      >
      > Bug: v8:9744
      > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64372}
      
      TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      
      Bug: v8:9744
      Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64477}
      dbbdd0ec
    • Clemens Backes's avatar
      Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" · 725e7dd7
      Clemens Backes authored
      This reverts commit 392a1217.
      
      Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747
      
      Original change's description:
      > Reland "Reland "[runtime] Remove extension slots from context objects""
      > 
      > This is a reland of c48096d4
      > 
      > Original change's description:
      > > Reland "[runtime] Remove extension slots from context objects"
      > >
      > > This is a reland of c07c02e1
      > >
      > > Original change's description:
      > > > [runtime] Remove extension slots from context objects
      > > >
      > > > Context objects have an extension slot, which contains further
      > > > additional data that depends on the type of the context.
      > > >
      > > > This CL removes the extension slot from contexts that don't need
      > > > them, hence reducing memory.
      > > >
      > > > The following contexts will still have an extension slot: native,
      > > > module, await, block and with contexts. See objects/contexts.h for
      > > > what the slot is used for.
      > > > The following contexts will not have an extension slot anymore (they
      > > > were not used before): script, catch and builtin contexts.
      > > > Eval and function contexts only have the extension slot if they
      > > > contain a sloppy eval.
      > > >
      > > > Bug: v8:9744
      > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > > > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > > Cr-Commit-Position: refs/heads/master@{#64372}
      > >
      > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      > >
      > > Bug: v8:9744
      > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > Cr-Commit-Position: refs/heads/master@{#64380}
      > 
      > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      > 
      > Bug: v8:9744
      > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64451}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com
      
      Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9744
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64453}
      725e7dd7
    • Victor Gomes's avatar
      Reland "Reland "[runtime] Remove extension slots from context objects"" · 392a1217
      Victor Gomes authored
      This is a reland of c48096d4
      
      Original change's description:
      > Reland "[runtime] Remove extension slots from context objects"
      >
      > This is a reland of c07c02e1
      >
      > Original change's description:
      > > [runtime] Remove extension slots from context objects
      > >
      > > Context objects have an extension slot, which contains further
      > > additional data that depends on the type of the context.
      > >
      > > This CL removes the extension slot from contexts that don't need
      > > them, hence reducing memory.
      > >
      > > The following contexts will still have an extension slot: native,
      > > module, await, block and with contexts. See objects/contexts.h for
      > > what the slot is used for.
      > > The following contexts will not have an extension slot anymore (they
      > > were not used before): script, catch and builtin contexts.
      > > Eval and function contexts only have the extension slot if they
      > > contain a sloppy eval.
      > >
      > > Bug: v8:9744
      > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > Cr-Commit-Position: refs/heads/master@{#64372}
      >
      > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      >
      > Bug: v8:9744
      > Change-Id: I0749cc2d8f59940c25841736634a70047116d647
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64380}
      
      TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      
      Bug: v8:9744
      Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@google.com>
      Cr-Commit-Position: refs/heads/master@{#64451}
      392a1217
  5. 27 Sep, 2019 1 commit
  6. 12 Sep, 2019 2 commits
    • Jakob Gruber's avatar
      Revert "[compiler] Optionally apply an offset to stack checks" · ba72dc08
      Jakob Gruber authored
      This reverts commit 4a16305b.
      
      Reason for revert: Need to revalidate assumptions behind the CHECK.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      > 
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      > 
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      > 
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      > 
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      > 
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534, chromium:1000887
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63706}
      ba72dc08
    • Jakob Gruber's avatar
      [compiler] Optionally apply an offset to stack checks · 4a16305b
      Jakob Gruber authored
      The motivation behind this change is that the frame size of an optimized
      function and its unoptimized version may differ, and deoptimization
      may thus trigger a stack overflow. The solution implemented in this CL
      is to optionally apply an offset to the stack check s.t. the check
      becomes 'sp - offset > limit'. The offset is applied to stack checks at
      function-entry, and is set to the difference between the optimized and
      unoptimized frame size.
      
      A caveat: OSR may not be fully handled by this fix since we've already
      passed the function-entry stack check. A possible solution would be to
      *not* skip creation of function-entry stack checks for inlinees.
      
      This CL: 1. annotates stack check nodes with the stack check kind, where
      kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      allocates a temporary register to store the result of the 'sp - offset'
      in instruction selection (and switches input registers to 'unique'
      mode). 3. Applies the offset in code generation.
      
      Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      
      Bug: v8:9534,chromium:1000887
      Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63701}
      4a16305b
  7. 06 Sep, 2019 1 commit
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored
      This is a reland of 8b89a7c3
      
      Reland after disabling the test getting deadlocked with '--gc_stress' flag.
      The CL was reverted because of the 'wasm/grow-shared-memory' test from
      the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
      the known issue (v8:9221) and the deadlocking test is now disabled (
      https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).
      
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      >
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      >
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      Bug: v8:9489,v8:9221
      Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
  8. 04 Sep, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "[compiler] improve inlining heuristics: call frequency per executed bytecodes" · eb443e1f
      Tobias Tebbi authored
      This reverts commit 352a154e.
      
      Reason for revert: https://crbug.com/999972
      
      Original change's description:
      > [compiler] improve inlining heuristics: call frequency per executed bytecodes
      > 
      > TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
      > compile time including off-thread, while improving Octane scores by ~2%.
      > 
      > How things used to work:
      > 
      > There is a flag FLAG_min_inlining_frequency that limits inlining by
      > the callsite being sufficiently frequently executed. This call frequency
      > was measured relative to invocations of the parent (= the function we
      > originally optimize). At the same time, the limit was very low (0.15),
      > meaning we mostly relied on the total amount of inlined code
      > (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
      > 
      > How things work now:
      > 
      > Instead of measuring call frequency relative to parent invocations, we
      > should have a measure that predicts how often the callsite in question
      > will be executed in the future. An obvious attempt at that would be to
      > measure how often the callsite was executed in absolute numbers in the
      > past. But depending on how fast feedback stabilizes, it can take more
      > or less time until we optimize a function. If we just take the absolute
      > call frequency up to the point in time when we optimize, we would
      > inline more for functions that stabilize slowly, which doesn't make
      > sense. So instead, we measure absolute call count per KB of executed
      > bytecodes of the parent function.
      > Since inlining big functions is more expensive, this threshold is
      > additionally scaled linearly with the bytecode-size of the inlinee.
      > The resulting formula is:
      > call_frequency >
      > FLAG_min_inlining_frequency *
      >   (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
      >   (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
      > 
      > The new threshold is chosen in a way that it effectively limits
      > inlining, which allows us to increase
      > FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
      > in general.
      > 
      > The reduction in compile time (x64 build) of ~10% was observed in Octane,
      > ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
      > The hope is that this will reduce CPU-time in real-world situations
      > too.
      > The Octane improvements come from inlining more in places where it
      > matters.
      > 
      > Bug: v8:6682
      > 
      > Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63449}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6682 chromium:999972
      Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63554}
      eb443e1f
  9. 03 Sep, 2019 2 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored
      This reverts commit 8b89a7c3.
      
      Reason for revert: GC Stress tests timing out.
      See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      > 
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      > 
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
      
      Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9489
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored
      The functionality of the GetIterator bytecode introduced previously is
      now extended from loading the @@iterator property to calling the property
      as well. This change basically absorbs the functionality of additional
      two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      Importantly, this change handles the cases of eager and lazy deoptimization
      in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      This mechanism can work as a template for the future bytecode that require
      handling such inter-bytecode deopt scenario. The tests evaluating the eager
      and lazy deopt scenarios are also included.
      
      Bug: v8:9489
      Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3
  10. 29 Aug, 2019 1 commit
    • Tobias Tebbi's avatar
      [compiler] improve inlining heuristics: call frequency per executed bytecodes · 352a154e
      Tobias Tebbi authored
      TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
      compile time including off-thread, while improving Octane scores by ~2%.
      
      How things used to work:
      
      There is a flag FLAG_min_inlining_frequency that limits inlining by
      the callsite being sufficiently frequently executed. This call frequency
      was measured relative to invocations of the parent (= the function we
      originally optimize). At the same time, the limit was very low (0.15),
      meaning we mostly relied on the total amount of inlined code
      (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
      
      How things work now:
      
      Instead of measuring call frequency relative to parent invocations, we
      should have a measure that predicts how often the callsite in question
      will be executed in the future. An obvious attempt at that would be to
      measure how often the callsite was executed in absolute numbers in the
      past. But depending on how fast feedback stabilizes, it can take more
      or less time until we optimize a function. If we just take the absolute
      call frequency up to the point in time when we optimize, we would
      inline more for functions that stabilize slowly, which doesn't make
      sense. So instead, we measure absolute call count per KB of executed
      bytecodes of the parent function.
      Since inlining big functions is more expensive, this threshold is
      additionally scaled linearly with the bytecode-size of the inlinee.
      The resulting formula is:
      call_frequency >
      FLAG_min_inlining_frequency *
        (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
        (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
      
      The new threshold is chosen in a way that it effectively limits
      inlining, which allows us to increase
      FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
      in general.
      
      The reduction in compile time (x64 build) of ~10% was observed in Octane,
      ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
      The hope is that this will reduce CPU-time in real-world situations
      too.
      The Octane improvements come from inlining more in places where it
      matters.
      
      Bug: v8:6682
      
      Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63449}
      352a154e
  11. 26 Aug, 2019 1 commit
  12. 23 Aug, 2019 2 commits
  13. 09 Aug, 2019 1 commit
  14. 17 Jul, 2019 1 commit
  15. 13 Jun, 2019 1 commit
  16. 24 May, 2019 1 commit
  17. 23 May, 2019 1 commit
  18. 14 May, 2019 1 commit
  19. 01 Apr, 2019 1 commit
  20. 29 Mar, 2019 1 commit
  21. 12 Mar, 2019 1 commit
  22. 01 Mar, 2019 1 commit
    • Matt Gardner's avatar
      Reland "Optimize `in` operator" · 803ad324
      Matt Gardner authored
      The original was reverted for breaking webkit layout tests:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
      
      It also caused the following clusterfuzz failures:
      
      chromium:935832
      This was a correctness bug due to not properly handling the case of arrays with prototypes other
      than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
      holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
      both in access-assembler and in Turbofan.
      
      chromium:935932
      This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
      code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
      debug builds but in release could show up in different places. This is the bug that caused the
      webkit layout test failure that led to the revert.
      
      Both bugs are fixed by in CL, and tests are added for those cases.
      
      Bug: v8:8733, chromium:935932, chromium:935832
      Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
      Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Matt Gardner <magardn@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#59958}
      803ad324
  23. 26 Feb, 2019 1 commit
  24. 25 Feb, 2019 1 commit
  25. 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
  26. 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
  27. 27 Sep, 2018 1 commit
  28. 25 Sep, 2018 1 commit
  29. 21 Sep, 2018 1 commit
  30. 05 Sep, 2018 1 commit
    • Hai Dang's avatar
      Reland "[interpreter] Add bytecode for leading array spreads." · 5f8a4272
      Hai Dang authored
      This is a reland of 1c48d52b.
      
      It turned out that IterableToList doesn't always behave according to
      the ES operation with the same name. Specifically, it allows holey arrays
      to take its fast path, which produces an output array with holes where
      actually "undefined" elements should appear.
      
      This CL changes the version of IterableToList that is used for spreads
      (IterableToListWithSymbolLookup) such that holey arrays take the slow path.
      It also includes tests for such situations.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      >
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      >
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      >
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      >
      > Bug: v8:7980
      >
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      Bug: v8:7980
      Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1201882
      Commit-Queue: Hai Dang <dhai@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55639}
      5f8a4272
  31. 31 Aug, 2018 1 commit
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored
      This reverts commit 1c48d52b.
      
      Reason for revert: Clusterfuzz found something.
      
      Original change's description:
      > [interpreter] Add bytecode for leading array spreads.
      > 
      > This CL improves the performance of creating [...a, b] or [...a].
      > If the array literal has a leading spread, this CL emits the bytecode
      > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      > is implemented by [IterableToListDefault] builtin to create the initial
      > array for the leading spread. IterableToListDefault has a fast path to
      > clone efficiently if the spread is an actual array.
      > 
      > The bytecode generated is now shorter. Bytecode generation is refactored
      > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      > from this optimization also.
      > For now, turbofan also lowers the bytecode to the builtin.
      > 
      > The idiomatic use of [...a] to clone the array a now performs better
      > than a simple for-loop, but still does not match the performance of slice.
      > 
      > Bug: v8:7980
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      > Reviewed-on: https://chromium-review.googlesource.com/1181024
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Cr-Commit-Position: refs/heads/master@{#55520}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
      
      Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7980
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
  32. 30 Aug, 2018 1 commit
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored
      This CL improves the performance of creating [...a, b] or [...a].
      If the array literal has a leading spread, this CL emits the bytecode
      [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
      is implemented by [IterableToListDefault] builtin to create the initial
      array for the leading spread. IterableToListDefault has a fast path to
      clone efficiently if the spread is an actual array.
      
      The bytecode generated is now shorter. Bytecode generation is refactored
      into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
      from this optimization also.
      For now, turbofan also lowers the bytecode to the builtin.
      
      The idiomatic use of [...a] to clone the array a now performs better
      than a simple for-loop, but still does not match the performance of slice.
      
      Bug: v8:7980
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
      Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Commit-Queue: Hai Dang <dhai@google.com>
      Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
  33. 02 Aug, 2018 1 commit
  34. 23 Jul, 2018 1 commit
  35. 20 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored
      As discussed in
      https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
      
      this CL introduces a new bytecode (CloneObject), and a new IC type.
      
      In this prototype implementation, the type feedback looks like the
      following:
      
      Uninitialized case:
        { uninitialized_sentinel, uninitialized_sentinel }
      Monomorphic case:
        { weak 'source' map, strong 'result' map }
      Polymorphic case:
        { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
      Megamorphic case:
        { megamorphic_sentinel, cleared_Value }
      
      In the fast case, Object cloning is done by allocating an object with
      the saved result map, and a shallow clone of the fast properties from
      the source object, as well as cloned fast elements from the source object.
      If at any point the fast case can't be taken, the IC transitions to the
      slow case and remains there.
      
      This prototype CL does not include any TurboFan optimization, and the
      CloneObject operation is merely reduced to a stub call.
      
      It may still be possible to get some further improvements by somehow
      incorporating compile-time boilerplate elements into the cloned object,
      or simplifying how the boilerplate elements are inserted into the
      object.
      
      In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
      by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
      
      R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
      BUG=v8:7611
      
      Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
      Reviewed-on: https://chromium-review.googlesource.com/1127472
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58