1. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  2. 24 Apr, 2019 1 commit
  3. 18 Apr, 2019 1 commit
  4. 15 Apr, 2019 1 commit
  5. 12 Apr, 2019 1 commit
  6. 02 Apr, 2019 1 commit
  7. 28 Mar, 2019 1 commit
  8. 20 Mar, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Turn {WasmCompileLazy} stub into a runtime stub. · 0feff465
      Michael Starzinger authored
      This removes the special casing for the lazy compilation stub which used
      to have its own code kind, just so that the stack walker would properly
      recognize its frame.
      
      Also, by re-using the existing machinery for runtime stubs we no longer
      need to copy this stub into the native module and get all the niceties
      that come with embedded builtins for free.
      
      Thirdly this will make it easier to start lazy compilation from the
      background or to do it on a per-function basis without requiring yet
      more special machinery, since {NativeModule::SetLazyBuiltin} no longer
      requires access to the Isolate.
      
      Kudos for the inspiration for this cleanup go to Frederik, I merely did
      some of the legwork.
      
      R=clemensh@chromium.org
      BUG=v8:8834
      
      Change-Id: Iac2b51a2e33fb0e88d25d3632fa18998123ee6c3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532064Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60365}
      0feff465
  9. 15 Mar, 2019 1 commit
  10. 04 Mar, 2019 1 commit
  11. 15 Feb, 2019 1 commit
  12. 14 Feb, 2019 1 commit
  13. 08 Feb, 2019 1 commit
    • Matheus Marchini's avatar
      Reland "[error] extend error stack w/ function parameters" · 3724a125
      Matheus Marchini authored
      This is a reland of 97628eee.
      
      Original change's description:
      > [error] extend error stack w/ function parameters
      >
      > Extend FrameArray to hold weak references to parameters forfunctions in
      > the call stack. The goal here is to provide more metadata for postmortem
      > tools (such as llnode), especially in cases of rethrowing (this will be
      > particularly useful when using postmortem with promises on Node.js).
      >
      > Besides postmortem, these changes allow us to print a more detailed
      > stack trace for errors with parameters types (or even values), which can
      > be useful since JavaScript functions can receive any number of
      > parameters of any type, and having a function behave differently
      > according to the number of parameters received as well as their types is
      > a common pattern on JS libraries and frameworks.
      >
      > R=<U+200B>bmeurer@google.com, yangguo@google.com
      >
      > Change-Id: Idf0984d0dbac16041f11d738d4b1c095a8eecd61
      > Reviewed-on: https://chromium-review.googlesource.com/c/1289489
      > Commit-Queue: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58468}
      
      R=bmeurer@google.com, jkummerow@chromium.org, yangguo@google.com
      
      Change-Id: I53d90bb862d9c5e9541116b375fa4de70e3e76dd
      Reviewed-on: https://chromium-review.googlesource.com/c/1405568
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59458}
      3724a125
  14. 05 Feb, 2019 1 commit
  15. 30 Jan, 2019 1 commit
  16. 25 Jan, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Support anyref stack parameters · 258371bd
      Andreas Haas authored
      Anyref parameters can exist across GC runs. Therefore the GC has to
      know where anyref parameters are on the stack so that it can mark them
      in its marking phase, and update them in the compaction phase.
      
      Already in a previous CL we grouped all anyref parameters so that they
      can be found more easily in a stack frame, see
      https://crrev.com/c/1371827. In this CL we implement the stack scanning
      itself.
      
      Note that anyref parameters are not scanned while iterating over the
      caller's frame (to which they actually belong), but while iterating
      over the callee's frame. The reason is that with tail-calls, only the
      callee knows how many tagged stack parameters (aka anyref parameters)
      there are.
      
      R=mstarzinger@chromium.org
      also-by=mstarzinger@chromium.org
      
      Bug: v8:7581
      Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7
      Reviewed-on: https://chromium-review.googlesource.com/c/1424955
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59099}
      258371bd
  17. 21 Jan, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Simplify safepoint-table encoding. · 6091e270
      Michael Starzinger authored
      This removes the unused "argument count" field from the safepoint table
      as the field was unused by now and always contained the value zero.
      
      Also note that associating a callee's argument count with the call-site
      is not compatible with tail-call support. When tail-calling a function
      with a different number of arguments, the information associated with
      the call-site becomes stale. The number of arguments is a property of
      the callee, not of the call-site in the caller. For this reason the
      field in question is not usable to support reference types in function
      arguments (at least when tail-calls are also supported).
      
      R=ahaas@chromium.org
      
      Change-Id: If667d729267f2dd2642b755c54235cc08ca9b141
      Reviewed-on: https://chromium-review.googlesource.com/c/1402548Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58969}
      6091e270
  18. 18 Jan, 2019 1 commit
  19. 08 Jan, 2019 1 commit
  20. 26 Dec, 2018 3 commits
  21. 21 Dec, 2018 3 commits
    • Sigurd Schneider's avatar
      Reland "[deoptimizer] Refactor GenerateDeoptimizationEntries" · 2a72b8ac
      Sigurd Schneider authored
      This is a reland of f63a657e
      
      Original change's description:
      > [deoptimizer] Refactor GenerateDeoptimizationEntries
      >
      > This reduces preprocessor-expanded source size by 64,359 from
      >
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,830 to   52,964,659 (  144x)
      > test        (  392 files):   490,924 to   37,360,916 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      >
      > to
      >
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,837 to   52,919,005 (  144x)
      > test        (  392 files):   490,924 to   37,342,211 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      >
      > Bug: v8:8562
      > Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1384091
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58424}
      
      TBR=jarin@chromium.org,ulan@chromium.org
      
      Bug: v8:8562
      Change-Id: I7a8a350414941f49c6155ff43e36e0cb0b2006e5
      Reviewed-on: https://chromium-review.googlesource.com/c/1387497Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58437}
      2a72b8ac
    • Sigurd Schneider's avatar
      Revert "[deoptimizer] Refactor GenerateDeoptimizationEntries" · 4b4175d7
      Sigurd Schneider authored
      This reverts commit f63a657e.
      
      Reason for revert: breaks compile on lite mode:
      
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8926535782549686576/+/steps/build/0/steps/compile/0/stdout
      
      
      Original change's description:
      > [deoptimizer] Refactor GenerateDeoptimizationEntries
      > 
      > This reduces preprocessor-expanded source size by 64,359 from
      > 
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,830 to   52,964,659 (  144x)
      > test        (  392 files):   490,924 to   37,360,916 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      > 
      > to
      > 
      > gen         (   21 files):    71,570 to    1,613,100 (   23x)
      > src         (  624 files):   367,837 to   52,919,005 (  144x)
      > test        (  392 files):   490,924 to   37,342,211 (   76x)
      > third_party (  432 files):   239,085 to    9,547,902 (   40x)
      > total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      > 
      > Bug: v8:8562
      > Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      > Reviewed-on: https://chromium-review.googlesource.com/c/1384091
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58424}
      
      TBR=ulan@chromium.org,jarin@chromium.org,sigurds@chromium.org
      
      Change-Id: I06e6f95255a3cea6a428713e9e841781425dffe8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8562
      Reviewed-on: https://chromium-review.googlesource.com/c/1387494Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58425}
      4b4175d7
    • Sigurd Schneider's avatar
      [deoptimizer] Refactor GenerateDeoptimizationEntries · f63a657e
      Sigurd Schneider authored
      This reduces preprocessor-expanded source size by 64,359 from
      
      gen         (   21 files):    71,570 to    1,613,100 (   23x)
      src         (  624 files):   367,830 to   52,964,659 (  144x)
      test        (  392 files):   490,924 to   37,360,916 (   76x)
      third_party (  432 files):   239,085 to    9,547,902 (   40x)
      total       ( 1521 files): 1,184,093 to  102,461,098 (   87x)
      
      to
      
      gen         (   21 files):    71,570 to    1,613,100 (   23x)
      src         (  624 files):   367,837 to   52,919,005 (  144x)
      test        (  392 files):   490,924 to   37,342,211 (   76x)
      third_party (  432 files):   239,085 to    9,547,902 (   40x)
      total       ( 1521 files): 1,184,100 to  102,396,739 (   86x)
      
      Bug: v8:8562
      Change-Id: Iee474e22ababa1e080b8d6359af4d0076903e59a
      Reviewed-on: https://chromium-review.googlesource.com/c/1384091Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58424}
      f63a657e
  22. 17 Dec, 2018 1 commit
  23. 14 Dec, 2018 1 commit
  24. 13 Dec, 2018 1 commit
    • Michael Starzinger's avatar
      [wasm] Allow storing of arguments count in a safepoint. · 366cddfa
      Michael Starzinger authored
      This overlays the "arguments count" and the "deoptimization index"
      fields within a safepoint entry. It allows for a larger value of
      arguments count to be stored in entries that do not contain a
      deoptimization index. Currently the arguments count is unused in
      TurboFan, but it will be used to handle reference type arguments in
      WebAssembly code.
      
      R=ahaas@chromium.org
      BUG=v8:7581
      
      Change-Id: I1e1d5af7e69288f046dc327de5d6e0466fc9ceaf
      Reviewed-on: https://chromium-review.googlesource.com/c/1371829
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58224}
      366cddfa
  25. 08 Dec, 2018 1 commit
  26. 07 Dec, 2018 2 commits
  27. 29 Nov, 2018 2 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 6c8b4102
      Peter Marshall authored
      This is a reland of d5f4a33e
      Landing with test disabled for now.
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      >
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      >
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      >
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      >
      > TBR=v8-mips-ports@googlegroups.com
      >
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=v8-mips-ports@googlegroups.com
      TBR=jgruber@chromium.org
      
      Bug: v8:8464, v8:7202
      Change-Id: I260d5ab3bc12c9c4529fb52a297a1040dcaa8ebf
      Reviewed-on: https://chromium-review.googlesource.com/c/1354466
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57935}
      6c8b4102
    • Michael Achenbach's avatar
      Revert "Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"" · 76786104
      Michael Achenbach authored
      This reverts commit ddaa1f0a.
      
      Reason for revert:
      Still flaky on windows. Maybe reland and keep skipped on windows?
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826
      
      Original change's description:
      > Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"
      > 
      > This is a reland of d5f4a33e
      > 
      > Original change's description:
      > > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      > >
      > > Before fast C calls, store the current FP and PC on the isolate. When
      > > iterating frames in SafeStackFrameIterator, check if these fields are
      > > set and start iterating at the calling frame's FP instead of the current
      > > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > > frame.
      > >
      > > This change makes stack samples that occur within 'Fast-C-Calls'
      > > iterable, meaning we can properly attribute ticks within the JS caller.
      > >
      > > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > > such call on the stack at a time, allowing us to store the FP on the
      > > isolate rather than the stack.
      > >
      > > TBR=v8-mips-ports@googlegroups.com
      > >
      > > Bug: v8:8464, v8:7202
      > > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#57896}
      > 
      > TBR=v8-mips-ports@googlegroups.com
      > TBR=jgruber@chromium.org
      > 
      > Bug: v8:8464, v8:7202
      > Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
      > Reviewed-on: https://chromium-review.googlesource.com/c/1354042
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57912}
      
      TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
      
      Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8464, v8:7202
      Reviewed-on: https://chromium-review.googlesource.com/c/1354461Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57925}
      76786104
  28. 28 Nov, 2018 4 commits
    • Jakob Kummerow's avatar
      [ubsan] Port SharedFunctionInfo to the new design · 81620900
      Jakob Kummerow authored
      Bug: v8:3770
      Change-Id: If405611d359d29ae1958beebd9202e068434a621
      Reviewed-on: https://chromium-review.googlesource.com/c/1350286
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57918}
      81620900
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · ddaa1f0a
      Peter Marshall authored
      This is a reland of d5f4a33e
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      >
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      >
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      >
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      >
      > TBR=v8-mips-ports@googlegroups.com
      >
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=v8-mips-ports@googlegroups.com
      TBR=jgruber@chromium.org
      
      Bug: v8:8464, v8:7202
      Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
      Reviewed-on: https://chromium-review.googlesource.com/c/1354042Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57912}
      ddaa1f0a
    • Maya Lekova's avatar
      Revert "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 2f530d5c
      Maya Lekova authored
      This reverts commit d5f4a33e.
      
      Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967
      
      Original change's description:
      > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
      > 
      > Before fast C calls, store the current FP and PC on the isolate. When
      > iterating frames in SafeStackFrameIterator, check if these fields are
      > set and start iterating at the calling frame's FP instead of the current
      > FP, which will be in C++ code. We need to do this because c_entry_fp is
      > not set on the Isolate for Fast-C-Calls because we don't build an exit
      > frame.
      > 
      > This change makes stack samples that occur within 'Fast-C-Calls'
      > iterable, meaning we can properly attribute ticks within the JS caller.
      > 
      > Fast-C-Calls can't call back into JS code, so we can only ever have one
      > such call on the stack at a time, allowing us to store the FP on the
      > isolate rather than the stack.
      > 
      > TBR=v8-mips-ports@googlegroups.com
      > 
      > Bug: v8:8464, v8:7202
      > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
      > Reviewed-by: Alexei Filippov <alph@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57896}
      
      TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
      
      Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8464, v8:7202
      Reviewed-on: https://chromium-review.googlesource.com/c/1352302Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57899}
      2f530d5c
    • Peter Marshall's avatar
      [cpu-profiler] Fix stack iterability for fast C calls with no exit frame · d5f4a33e
      Peter Marshall authored
      Before fast C calls, store the current FP and PC on the isolate. When
      iterating frames in SafeStackFrameIterator, check if these fields are
      set and start iterating at the calling frame's FP instead of the current
      FP, which will be in C++ code. We need to do this because c_entry_fp is
      not set on the Isolate for Fast-C-Calls because we don't build an exit
      frame.
      
      This change makes stack samples that occur within 'Fast-C-Calls'
      iterable, meaning we can properly attribute ticks within the JS caller.
      
      Fast-C-Calls can't call back into JS code, so we can only ever have one
      such call on the stack at a time, allowing us to store the FP on the
      isolate rather than the stack.
      
      TBR=v8-mips-ports@googlegroups.com
      
      Bug: v8:8464, v8:7202
      Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
      Reviewed-on: https://chromium-review.googlesource.com/c/1340241
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMartyn Capewell <martyn.capewell@arm.com>
      Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57896}
      d5f4a33e
  29. 27 Nov, 2018 1 commit
  30. 25 Nov, 2018 2 commits