1. 29 Oct, 2019 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Fix location computation from interpreted frames · 700f9b0e
      Clemens Backes authored
      The {IsWasmFrame} check in {ComputeLocationFromStackTrace} only returned
      true for compiled frames, but not for interpreted ones. Thus, for
      interpreted frames we would run into the code for JS frames, which
      assumes that a {JSFunction} is available.
      
      This CL fixes this issue by renaming {IsWasmFrame} to
      {IsWasmCompiledFrame}, and introducing a new {IsWasmFrame} method which
      returns true for both compiled and interpreted frames.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:1018227
      Change-Id: If83b4129edaad775a212ccb741f3c62eabc2addb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883892Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64607}
      700f9b0e
  2. 23 May, 2019 1 commit
  3. 25 Mar, 2019 1 commit
  4. 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
  5. 06 Feb, 2019 1 commit
  6. 09 Jan, 2019 1 commit
  7. 08 Jan, 2019 1 commit
  8. 26 Dec, 2018 2 commits
    • Jakob Kummerow's avatar
      Revert "[error] extend error stack w/ function parameters" · 444741ac
      Jakob Kummerow authored
      This reverts commit 97628eee.
      
      Reason for revert: breaks compilation in Lite mode, which does not allow overriding of certain flags. See https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8926078411629093216/+/steps/build/0/steps/compile/0/stdout.
      
      Original change's description:
      > [error] extend error stack w/ function parameters
      > 
      > Extend FrameArray to hold weak references to parameters for functions 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=​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}
      
      TBR=yangguo@chromium.org,bmeurer@google.com,bmeurer@chromium.org,mat@mmarchini.me
      
      Change-Id: Ide0a434c1521ab2bbeca6821397ff63ba7d40fe5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/1390128Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58469}
      444741ac
    • Matheus Marchini's avatar
      [error] extend error stack w/ function parameters · 97628eee
      Matheus Marchini authored
      Extend FrameArray to hold weak references to parameters for functions 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=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: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58468}
      97628eee
  9. 25 Nov, 2018 1 commit
  10. 24 Nov, 2018 1 commit
  11. 05 Nov, 2018 1 commit
  12. 26 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Add Promise.all() support to --async-stack-traces. · 6f39ab89
      Benedikt Meurer authored
      This adds support for Promise.all() to --async-stack-traces (also at
      zero cost, since we can derive the relevant information from the resolve
      element closure and context). In case of `Promise.all(a)` the stack
      trace even tells you which element of `a` is responsible, for example
      
      ```js
      async function fine() {}
      async function thrower() { await fine(); throw new Error(); }
      async function test() { await Promise.all([fine(), thrower()]); }
      ```
      
      will generate the following stack trace
      
      ```
      Error
          at thrower (something.js:1:9)
          at async Promise.all (index 1)
          at async test (something.js:3:3)
      ```
      
      so it not only shows the async Promise.all() frames, but even tells the
      user exactly that the second element of `[fine(), thrower()]` is the
      relevant one.
      
      Bug: v8:7522
      Change-Id: I279a845888e06053cf0e3c9338ab71caabaabf45
      Reviewed-on: https://chromium-review.googlesource.com/c/1299248Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57023}
      6f39ab89
  13. 04 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] First prototype of zero-cost async stack traces. · f537d778
      Benedikt Meurer authored
      This introduces a new flag --async-stack-traces, which enables zero-cost
      async stack traces. This enriches the non-standard Error.stack property
      with async stack frames computed from walking up the promise chains and
      collecting all the await suspension points along the way. In Error.stack
      these async frames are marked with "async" to make it possible to
      distinguish them from regular frames, for example:
      
      ```
      Error: Some error message
          at bar (<anonymous>)
          at async foo (<anonymous>)
      ```
      
      It's zero-cost because no additional information is collected during the
      execution of the program, but only the information already present in the
      promise chains is used to reconstruct an approximation of the async stack
      in case of an exception. But this approximation is limited to suspension
      points at await's in async functions. This depends on a recent ECMAScript
      specification change, flagged behind --harmony-await-optimization and
      implied the --async-stack-traces flag. Without this change there's no
      way to get from the outer promise of an async function to the rest of
      the promise chain, since the link is broken by the indirection introduced
      by await.
      
      For async functions the special outer promise, named .promise in the
      Parser desugaring, is now forcible allocated to stack slot 0 during
      scope resolution, to make it accessible to the stack frame construction
      logic. Note that this first prototype doesn't yet work fully support
      async generators and might have other limitations.
      
      Bug: v8:7522
      Ref: nodejs/node#11865
      Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9
      Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
      Reviewed-on: https://chromium-review.googlesource.com/c/1256762
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56363}
      f537d778
  14. 10 Aug, 2018 1 commit
  15. 13 Jul, 2018 1 commit
  16. 11 Jul, 2018 1 commit
  17. 14 Mar, 2018 1 commit
  18. 28 Nov, 2017 3 commits
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] JIT using WasmCodeManager"" · b03b1bd9
      Mircea Trofin authored
      This reverts commit b301203e.
      
      Reason for revert: Fixed issues on arm.
      
      Original change's description:
      > Revert "[wasm] JIT using WasmCodeManager"
      > 
      > This reverts commit d4c8393c.
      > 
      > Reason for revert: Breaks ARM hardware:
      > https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
      > 
      > Original change's description:
      > > [wasm] JIT using WasmCodeManager
      > > 
      > > This is the first step towards wasm code sharing. This CL moves wasm
      > > code generation outside the JavaScript GC heap using the previously -
      > > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      > > flag).
      > > 
      > > See design document: go/wasm-on-native-heap-stage-1
      > > 
      > > This CL doesn't change other wasm architectural invariants. We still
      > > have per-Isolate wasm code generation, and per-wasm module instance
      > > code specialization.
      > > 
      > > Bug:v8:6876
      > > 
      > > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      > > Reviewed-on: https://chromium-review.googlesource.com/674086
      > > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > > Reviewed-by: Eric Holk <eholk@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#49689}
      > 
      > TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      > 
      > Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6876
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/794690
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49691}
      
      TBR=bradnelson@chromium.org,machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: I1b07638d1bb2ba0664305b4b2dcfc1342dc8444f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6876
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/794434
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49692}
      b03b1bd9
    • Michael Achenbach's avatar
      Revert "[wasm] JIT using WasmCodeManager" · b301203e
      Michael Achenbach authored
      This reverts commit d4c8393c.
      
      Reason for revert: Breaks ARM hardware:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
      
      Original change's description:
      > [wasm] JIT using WasmCodeManager
      > 
      > This is the first step towards wasm code sharing. This CL moves wasm
      > code generation outside the JavaScript GC heap using the previously -
      > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      > flag).
      > 
      > See design document: go/wasm-on-native-heap-stage-1
      > 
      > This CL doesn't change other wasm architectural invariants. We still
      > have per-Isolate wasm code generation, and per-wasm module instance
      > code specialization.
      > 
      > Bug:v8:6876
      > 
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      > Reviewed-on: https://chromium-review.googlesource.com/674086
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49689}
      
      TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6876
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/794690Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49691}
      b301203e
    • Mircea Trofin's avatar
      [wasm] JIT using WasmCodeManager · d4c8393c
      Mircea Trofin authored
      This is the first step towards wasm code sharing. This CL moves wasm
      code generation outside the JavaScript GC heap using the previously -
      introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      flag).
      
      See design document: go/wasm-on-native-heap-stage-1
      
      This CL doesn't change other wasm architectural invariants. We still
      have per-Isolate wasm code generation, and per-wasm module instance
      code specialization.
      
      Bug:v8:6876
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      Reviewed-on: https://chromium-review.googlesource.com/674086Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49689}
      d4c8393c
  19. 29 Jun, 2017 1 commit
  20. 16 Jun, 2017 1 commit
  21. 12 Jun, 2017 1 commit
  22. 24 Mar, 2017 1 commit