- 18 Sep, 2020 2 commits
-
-
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:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69999}
-
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:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69990}
-
- 17 Sep, 2020 2 commits
-
-
Peter Marshall authored
This reverts commit f6965281. Reason for revert: Test is flaky: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64/39092 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} TBR=mythria@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org Change-Id: I1e69f8af88d901bab6f257652d3536d24a4777f9 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2415994Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#69969}
-
Peter Marshall authored
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}
-
- 05 Aug, 2020 1 commit
-
-
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:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 27 Sep, 2019 3 commits
-
-
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:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64023}
-
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:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#64015}
-
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:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64014}
-