1. 18 Sep, 2020 2 commits
    • Peter Marshall's avatar
      Revert "Reland "[cpu-profiler] Log OSR code when starting the profiler"" · 15a78f97
      Peter Marshall authored
      This reverts commit 8b60d8fc.
      
      Reason for revert: Flaky on windows: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/27302
      
      Original change's description:
      > Reland "[cpu-profiler] Log OSR code when starting the profiler"
      > 
      > This is a reland of f6965281
      > 
      > Updated the test:
      > 1. Set profiling interval to 100us to get 10x the samples
      > 2. Guarantee we spend at least 1ms per iteration, instead of only
      > bailing out if we spend more than 1ms. This gives us enough samples on
      > release mode.
      > 3. Increase the time spent profiling optimized code by 50% to make sure
      > we have a big enough difference.
      > 
      > With 1000 iterations I didn't see any flakes locally so this looks solid
      > now.
      > 
      > Original change's description:
      > > [cpu-profiler] Log OSR code when starting the profiler
      > >
      > > OSR code doesn't hang off any JSFunction or SFI, so we missed it when
      > > starting up the profiler. This meant we didn't properly attribute
      > > ticks to SFI code. The ticks ended up going to the caller instead.
      > >
      > > There is a weak cache of OSR code per native context, so iterate that
      > > on profiler startup and log all the code objects.
      > >
      > > Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
      > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#69964}
      > 
      > Change-Id: Ib506e88b546008e462967259763bbf985b74b462
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69990}
      
      TBR=mythria@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
      
      Change-Id: Ie3272c4fd297ca6f10a47c3fe8826e226a9f0545
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418714Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69999}
      15a78f97
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Log OSR code when starting the profiler" · 8b60d8fc
      Peter Marshall authored
      This is a reland of f6965281
      
      Updated the test:
      1. Set profiling interval to 100us to get 10x the samples
      2. Guarantee we spend at least 1ms per iteration, instead of only
      bailing out if we spend more than 1ms. This gives us enough samples on
      release mode.
      3. Increase the time spent profiling optimized code by 50% to make sure
      we have a big enough difference.
      
      With 1000 iterations I didn't see any flakes locally so this looks solid
      now.
      
      Original change's description:
      > [cpu-profiler] Log OSR code when starting the profiler
      >
      > OSR code doesn't hang off any JSFunction or SFI, so we missed it when
      > starting up the profiler. This meant we didn't properly attribute
      > ticks to SFI code. The ticks ended up going to the caller instead.
      >
      > There is a weak cache of OSR code per native context, so iterate that
      > on profiler startup and log all the code objects.
      >
      > Change-Id: I2e9738b86a488b37f36ac89803561607dc76f745
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414216
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69964}
      
      Change-Id: Ib506e88b546008e462967259763bbf985b74b462
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418092
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69990}
      8b60d8fc
  2. 17 Sep, 2020 2 commits
  3. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  4. 27 Sep, 2019 3 commits
    • Mythri A's avatar
      Reland "[compiler] Cache OSR optimized code" · fcff2437
      Mythri A authored
      This is a reland of cfb10028
      with a fix for failures in lite mode.
      
      Original change's description:
      > [compiler] Cache OSR optimized code
      >
      > With lazy feedback allocation, for functions that get OSRed we may
      > not have feedback for the initial part of the functions since feedback
      > vectors might be allocated after the function started executing. Hence
      > we would not be able to optimize the function on the next call. This
      > means we may have to OSR twice before we actually optimize function.
      > This cl introduces OSR cache, so we could reuse the optimized code. One
      > side effect of this cl is that the OSRed code won't be function context
      > specialized anymore.
      >
      > Bug: chromium:987523
      > Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64014}
      
      Bug: chromium:987523
      Change-Id: I9c782242b07b24d15247533ab4ee044334b429ff
      TBR: rmcilroy@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826898
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64023}
      fcff2437
    • Michael Achenbach's avatar
      Revert "[compiler] Cache OSR optimized code" · f8a08223
      Michael Achenbach authored
      This reverts commit cfb10028.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/6483
      
      Original change's description:
      > [compiler] Cache OSR optimized code
      > 
      > With lazy feedback allocation, for functions that get OSRed we may
      > not have feedback for the initial part of the functions since feedback
      > vectors might be allocated after the function started executing. Hence
      > we would not be able to optimize the function on the next call. This
      > means we may have to OSR twice before we actually optimize function.
      > This cl introduces OSR cache, so we could reuse the optimized code. One
      > side effect of this cl is that the OSRed code won't be function context
      > specialized anymore.
      > 
      > Bug: chromium:987523
      > Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
      > Commit-Queue: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64014}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org
      
      Change-Id: Ib3692e7570bed5d3e88ca8a0247b185d70497a04
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:987523
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826668Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64015}
      f8a08223
    • Mythri A's avatar
      [compiler] Cache OSR optimized code · cfb10028
      Mythri A authored
      With lazy feedback allocation, for functions that get OSRed we may
      not have feedback for the initial part of the functions since feedback
      vectors might be allocated after the function started executing. Hence
      we would not be able to optimize the function on the next call. This
      means we may have to OSR twice before we actually optimize function.
      This cl introduces OSR cache, so we could reuse the optimized code. One
      side effect of this cl is that the OSRed code won't be function context
      specialized anymore.
      
      Bug: chromium:987523
      Change-Id: Ic1e2abca85ccfa0a66a0fa83f7247392cc1e7cb2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796329
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64014}
      cfb10028