1. 23 May, 2019 2 commits
  2. 22 May, 2019 1 commit
  3. 21 May, 2019 1 commit
  4. 16 May, 2019 1 commit
  5. 25 Mar, 2019 3 commits
    • Benedikt Meurer's avatar
      [cleanup] Remove obsolete --type_info_threshold flag. · 19dcbec8
      Benedikt Meurer authored
      The --type_info_threshold is no longer supported for a long time and
      doesn't do anything useful nowadays, so no point in having that around.
      
      Drive-by-fix: Remove the FeedbackVector::ComputeCounts() logic, since
      it's dead code anyways by now.
      
      Bug: v8:8834
      Change-Id: I05f7517b3b82e34c0a83357337a456ab9c9f1f42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538128
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60442}
      19dcbec8
    • Benedikt Meurer's avatar
      [turbofan] Remove duplicated optimization limit. · 077e49a1
      Benedikt Meurer authored
      Before this change we had essentially two optimization limits, one hard
      limit in the TurboFan pipeline (128KiB), and a soft limit in the runtime
      profiler (60KiB). The hard limit was only relevant to --always-opt and
      other internal test infrastructure, and the soft limit was always
      enforced on regular JavaScript, but didn't properly disable further
      optimization for the function (so for example --trace-opt would
      continuesly report attempts to optimize the function).
      
      Now with this change we only have the hard limit, set to 60KiB, in the
      TurboFan pipeline and use that consistently.
      
      Bug: v8:8598
      Change-Id: I9e2ae7cb67de4a2256d3a7b9c3aee3dab60c2ec1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538127
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60436}
      077e49a1
    • Benedikt Meurer's avatar
      [tracing] Properly trace stack guards and interrupts. · b8490293
      Benedikt Meurer authored
      Add tracing support for the %StackGuard() and %Interrupt() runtime calls
      and the individual actions performed in StackGuard::HandleInterrupts().
      This includes:
      
       - "V8.GCHandleGCRequest" (in "disabled-by-default-v8.gc") when the
         GC_REQUEST bit is set.
       - "V8.WasmGrowSharedMemory" (in "disabled-by-default-v8.wasm") when
         the GROW_SHARED_MEMORY bit is set.
       - "V8.TerminateExecution" (in "v8.execute") when the
         TERMINATE_EXECUTION bit is set.
       - "V8.GCDeoptMarkedAllocationSites" (in "disabled-by-default-v8.gc")
         when the DEOPT_MARKED_ALLOCATION_SITES bit is set.
       - "V8.InstallOptimizedFunctions" (in "disabled-by-default-v8.compile")
         when the INSTALL_CODE bit is set.
       - "V8.InvokeApiInterruptCallbacks" (in "v8.execute") when the
         API_INTERRUPT bit is set.
      
      Now we also emit a trace event "V8.MarkCandidatesForOptimization" (in
      "disabled-by-default-v8.compile") in addition to the above from the
      RuntimeProfiler when we mark candidates for optimization at the end
      of each stack check.
      
      An example of the "V8.InstallOptimizedFunctions" in action (in the
      trace viewer) can be seen here:
      
        https://i.paste.pics/094a04af035eedc0690cd4079afa28f1.png
      
      This supersedes the previously introduced --trace-interrupts CLI flag,
      which is thus removed as part of this change.
      
      Bug: v8:8598
      Change-Id: I3c3375d00b07cbe700b6912097d7264031ace802
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538116
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60428}
      b8490293
  6. 08 Dec, 2018 1 commit
  7. 07 Dec, 2018 3 commits
  8. 30 Nov, 2018 1 commit
  9. 28 Nov, 2018 1 commit
  10. 24 Nov, 2018 1 commit
  11. 20 Nov, 2018 1 commit
  12. 02 Nov, 2018 2 commits
    • Ross McIlroy's avatar
      Reland "Get BytecodeArray via current frame where possible." · 3530998c
      Ross McIlroy authored
      This is a reland of 7350e7b2
      
      Disabled LayoutTest that was causing issues and will rebaseline once this has rolled.
      
      Original change's description:
      > Get BytecodeArray via current frame where possible.
      >
      > With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
      > Instead of getting the bytecode array from the SFI, get it from the frame instead
      > (which is a strong pointer). Note: This won't actually change behaviour since the
      > fact that the bytecode array was on the frame will retain it strongly, however it
      > makes the contract that the BytecodeArray must exist at these points more explicit.
      >
      > Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
      >
      > BUG=v8:8395
      >
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
      > Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
      > Reviewed-on: https://chromium-review.googlesource.com/c/1310193
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57198}
      
      TBR=mythria@chromium.org
      
      Bug: v8:8395
      Change-Id: I63044138f876a1cdfb8bb71499732a257f30d29a
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1314336Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57219}
      3530998c
    • Maya Lekova's avatar
      Revert "Get BytecodeArray via current frame where possible." · ea27a244
      Maya Lekova authored
      This reverts commit 7350e7b2.
      
      Reason for revert: Braking layout test, blocking the roll, see
      https://bugs.chromium.org/p/v8/issues/detail?id=8405
      
      Original change's description:
      > Get BytecodeArray via current frame where possible.
      > 
      > With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
      > Instead of getting the bytecode array from the SFI, get it from the frame instead
      > (which is a strong pointer). Note: This won't actually change behaviour since the
      > fact that the bytecode array was on the frame will retain it strongly, however it
      > makes the contract that the BytecodeArray must exist at these points more explicit.
      > 
      > Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
      > 
      > BUG=v8:8395
      > 
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
      > Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
      > Reviewed-on: https://chromium-review.googlesource.com/c/1310193
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57198}
      
      TBR=rmcilroy@chromium.org,mythria@chromium.org
      
      Change-Id: Ie5db0ec1d68ca01d62e9880a4476704ad4d013b5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8395
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1314330Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57205}
      ea27a244
  13. 01 Nov, 2018 1 commit
    • Ross McIlroy's avatar
      Get BytecodeArray via current frame where possible. · 7350e7b2
      Ross McIlroy authored
      With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
      Instead of getting the bytecode array from the SFI, get it from the frame instead
      (which is a strong pointer). Note: This won't actually change behaviour since the
      fact that the bytecode array was on the frame will retain it strongly, however it
      makes the contract that the BytecodeArray must exist at these points more explicit.
      
      Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
      
      BUG=v8:8395
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
      Reviewed-on: https://chromium-review.googlesource.com/c/1310193
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57198}
      7350e7b2
  14. 10 Apr, 2018 1 commit
    • Matheus Marchini's avatar
      interpreter: make interpreted frames distinguishable in the native stack · ada64b58
      Matheus Marchini authored
      Before Turbofan/Ignition it was possible to use external profilers to
      sample running V8/Node.js processes and generate reports/FlameGraphs
      from that. It's still possible to do so, but non-optimized JavaScript
      functions appear in the stack as InterpreterEntryTrampoline. This commit
      adds a runtime flag which makes interpreted frames visible on the
      process' native stack as distinguishable functions, making the sampled
      data gathered by external profilers such as Linux perf and DTrace more
      useful.
      
      R=bmeurer@google.com, franzih@google.com, jarin@google.com, yangguo@google.com
      
      Bug: v8:7155
      Change-Id: I3dc8876aa3cd9f1b9766624842a7cc354ccca415
      Reviewed-on: https://chromium-review.googlesource.com/959081
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52533}
      ada64b58
  15. 17 Oct, 2017 1 commit
  16. 19 Sep, 2017 1 commit
    • Mythri's avatar
      Change runtime_profiler to use bytecode array length · 807d0abe
      Mythri authored
      Runtime profiler uses bytecode array size for the tiering up decisions.
      Bytecode array size includes the header size as well. Inlining
      heuristics use bytecode array length instead. Bytecode array length
      is just the size of bytecode not inlcuding any headers. This change
      is to keep both of them in sync to avoid confusion. Also, the header
      contains several pointers and hence the size changes depending on the
      size of kPointerSize.
      
      Bug: 
      Change-Id: I22a9cf5e0bb9d6853c6a8be8d69c9ff459418a0d
      Reviewed-on: https://chromium-review.googlesource.com/670724Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48081}
      807d0abe
  17. 13 Sep, 2017 1 commit
  18. 11 Sep, 2017 1 commit
  19. 05 Sep, 2017 2 commits
  20. 31 Aug, 2017 1 commit
  21. 10 Aug, 2017 1 commit
  22. 03 Aug, 2017 1 commit
  23. 28 Jul, 2017 1 commit
  24. 25 Jul, 2017 1 commit
  25. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      Leszek Swirski authored
      This reverts commit a2fcdc7c.
      
      Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
      
      Original change's description:
      > [runtime] Move profiler ticks from SFI to feedback vector
      > 
      > Instead of counting profiler ticks on the shared function info (which is
      > shared between native contexts), count them on the feedback vector
      > (which is not). This allows us to continue pushing optimization
      > decisions off the SFI, onto the feedback vector.
      > 
      > Note that a side-effect of this is that ICs don't have to walk the stack
      > to reset profiler ticks, as they can access the feedback vector directly
      > from their feedback nexus.
      > 
      > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
      > Reviewed-on: https://chromium-review.googlesource.com/544888
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46411}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
      Reviewed-on: https://chromium-review.googlesource.com/574227
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  26. 05 Jul, 2017 1 commit
  27. 21 Jun, 2017 1 commit
  28. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback
      vector to store an optimization marker (optimize/in optimization queue)
      rather than changing the JSFunction's code object. Then, adapt the
      self-healing mechanism to also dispatch based on this optimization
      marker. Similarly, replace SFI marking with optimization marker checks
      in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing
      shared function marking) without leaking this information across native
      contexts. Non I+TF functions (asm.js or --no-turbo) use a
      CheckOptimizationMarker shim which generalises the old
      CompileOptimized/InOptimizationQueue builtins and also checks the same
      optimization marker as CompileLazy and InterpreterEntryTrampoline.
      
      This is a reland of https://chromium-review.googlesource.com/c/509716
      
      Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
      Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  29. 13 Jun, 2017 3 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored
      This reverts commit e39c9e02.
      
      Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561
      
      Original change's description:
      > [compiler] Drive optimizations with feedback vector
      > 
      > For interpreted functions, use the optimized code slot in the feedback vector
      > to store an optimization marker (optimize/in optimization queue) rather than
      > changing the JSFunction's code object. Then, adapt the self-healing mechanism
      > to also dispatch based on this optimization marker. Similarly, replace SFI
      > marking with optimization marker checks in CompileLazy.
      > 
      > This allows JSFunctions to share optimization information (replacing shared
      > function marking) without leaking this information across native contexts. Non
      > I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      > generalises the old CompileOptimized/InOptimizationQueue builtins and also
      > checks the same optimization marker as CompileLazy and
      > InterpreterEntryTrampoline.
      > 
      > Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      > Reviewed-on: https://chromium-review.googlesource.com/509716
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45901}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      
      Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
      Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback vector
      to store an optimization marker (optimize/in optimization queue) rather than
      changing the JSFunction's code object. Then, adapt the self-healing mechanism
      to also dispatch based on this optimization marker. Similarly, replace SFI
      marking with optimization marker checks in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing shared
      function marking) without leaking this information across native contexts. Non
      I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
      generalises the old CompileOptimized/InOptimizationQueue builtins and also
      checks the same optimization marker as CompileLazy and
      InterpreterEntryTrampoline.
      
      Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
      Reviewed-on: https://chromium-review.googlesource.com/509716
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
    • Leszek Swirski's avatar
      [runtime] Don't count profiler ticks on Code objects · 09637ab3
      Leszek Swirski authored
      With the deprecation of Crankshaft, it's no longer necessary for
      FullCodeGen to keep track of its runtime profiler ticks on the code
      object, and we can instead unify the behaviour of FCG and Ignition to
      both increment the SFI counter instead.
      
      Bug: v8:6408
      Change-Id: Idcdd673aa39af06fe15a0fc14dfda2afafb5e417
      Reviewed-on: https://chromium-review.googlesource.com/528117Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45892}
      09637ab3
  30. 06 Jun, 2017 1 commit
  31. 15 May, 2017 1 commit