1. 19 Apr, 2018 1 commit
  2. 11 Apr, 2018 1 commit
  3. 05 Apr, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      Reland "[debug] introduced runtime side effect check" · 71018812
      Alexey Kozyatinskiy authored
      This is a reland of 7a2c3713
      
      Original change's description:
      > [debug] introduced runtime side effect check
      > 
      > This CL demonstrates minimum valuable addition to existing debug evaluate
      > without side effects mechanism.
      > With this CL user can evaluate expressions like:
      > [a,b] // create any kind of temporary array literals
      > [a,b].reduce((x,y) => x + y, 0); // use reduce method
      > [1,2,3].fill(2); // change temporary arrays
      > 
      > The core idea: any change of the object created during evaluation without
      > side effects is side effect free. As soon as we try to store this temporary
      > object to object existed before evaluation we will terminate execution.
      > 
      > Implementation:
      > - track all objects allocated during evaluation and mark them as temporary,
      > - patch all bytecodes which change objects.
      > 
      > A little more details (including performance analysis): [1].
      > 
      > [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      > 
      > Bug: v8:7588
      > Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      > Reviewed-on: https://chromium-review.googlesource.com/972615
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52370}
      
      Bug: v8:7588
      Change-Id: Ibc92bf19155f2ddaedae39b0c576b994e84afcf8
      Reviewed-on: https://chromium-review.googlesource.com/996760Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52373}
      71018812
  4. 04 Apr, 2018 3 commits
    • Aleksey Kozyatinskiy's avatar
      Revert "[debug] introduced runtime side effect check" · 539a2443
      Aleksey Kozyatinskiy authored
      This reverts commit 7a2c3713.
      
      Reason for revert: msan is broken
      
      Original change's description:
      > [debug] introduced runtime side effect check
      > 
      > This CL demonstrates minimum valuable addition to existing debug evaluate
      > without side effects mechanism.
      > With this CL user can evaluate expressions like:
      > [a,b] // create any kind of temporary array literals
      > [a,b].reduce((x,y) => x + y, 0); // use reduce method
      > [1,2,3].fill(2); // change temporary arrays
      > 
      > The core idea: any change of the object created during evaluation without
      > side effects is side effect free. As soon as we try to store this temporary
      > object to object existed before evaluation we will terminate execution.
      > 
      > Implementation:
      > - track all objects allocated during evaluation and mark them as temporary,
      > - patch all bytecodes which change objects.
      > 
      > A little more details (including performance analysis): [1].
      > 
      > [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      > 
      > Bug: v8:7588
      > Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      > Reviewed-on: https://chromium-review.googlesource.com/972615
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52370}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,leszeks@chromium.org
      
      Change-Id: Ied1739c6308b13a4981189e0999f5912316cf456
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7588
      Reviewed-on: https://chromium-review.googlesource.com/996135Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52371}
      539a2443
    • Alexey Kozyatinskiy's avatar
      [debug] introduced runtime side effect check · 7a2c3713
      Alexey Kozyatinskiy authored
      This CL demonstrates minimum valuable addition to existing debug evaluate
      without side effects mechanism.
      With this CL user can evaluate expressions like:
      [a,b] // create any kind of temporary array literals
      [a,b].reduce((x,y) => x + y, 0); // use reduce method
      [1,2,3].fill(2); // change temporary arrays
      
      The core idea: any change of the object created during evaluation without
      side effects is side effect free. As soon as we try to store this temporary
      object to object existed before evaluation we will terminate execution.
      
      Implementation:
      - track all objects allocated during evaluation and mark them as temporary,
      - patch all bytecodes which change objects.
      
      A little more details (including performance analysis): [1].
      
      [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      
      Bug: v8:7588
      Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      Reviewed-on: https://chromium-review.googlesource.com/972615
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52370}
      7a2c3713
    • Andrey Lushnikov's avatar
      DevTools: Runtime.callFunctionOn should allow evals · 16378186
      Andrey Lushnikov authored
      This patch teaches Runtime.callFunctionOn to run evals inside its
      task. This is aligned with how Runtime.evaluate works.
      
      R=kozy
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I3189beebc9020703d2b2e23a7c828a2394d43910
      Reviewed-on: https://chromium-review.googlesource.com/994070
      Commit-Queue: Andrey Lushnikov <lushnikov@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52339}
      16378186
  5. 09 Mar, 2018 1 commit
  6. 08 Mar, 2018 1 commit
  7. 27 Feb, 2018 3 commits
    • Ross McIlroy's avatar
      Reland: [Compiler] Use CompilationCache for StreamedScript compilation. · 910f45fa
      Ross McIlroy authored
      Previously GetSharedFunctionInfoForStreamedScript didn't either check the
      compilation cache or put the result of compilation into the compilation
      cache. This would mean future compiles would need to re-parse / compile
      the same script even if the isolate had already seen it. This CL
      fixes this.
      
      Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile()
      for all script compiles even when loading from a cache.
      
      BUG=v8:5203
      
      Change-Id: I4b06bdfc566425f4e6d70fc3e6e080b0dc497d48
      Reviewed-on: https://chromium-review.googlesource.com/939464
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51607}
      910f45fa
    • Clemens Hammacher's avatar
      Revert "Reland: [Compiler] Use CompilationCache for StreamedScript compilation." · d7e59efa
      Clemens Hammacher authored
      This reverts commit 25427203.
      
      Reason for revert: code-coverage failures on gc-stress bot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/17956
      
      Original change's description:
      > Reland: [Compiler] Use CompilationCache for StreamedScript compilation.
      > 
      > Previously GetSharedFunctionInfoForStreamedScript didn't either check the
      > compilation cache or put the result of compilation into the compilation
      > cache. This would mean future compiles would need to re-parse / compile
      > the same script even if the isolate had already seen it. This CL
      > fixes this.
      > 
      > Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile()
      > for all script compiles even when loading from a cache.
      > 
      > BUG=v8:5203
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > 
      > Change-Id: I0a74c5b67bfaca5e50511d5f72da0ab53d8457f6
      > Reviewed-on: https://chromium-review.googlesource.com/937724
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#51594}
      
      TBR=rmcilroy@chromium.org,yangguo@chromium.org,mythria@chromium.org
      
      Change-Id: I784b9eeff75a677b9f2276fa05a0d1af09772baa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5203
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/939401Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51596}
      d7e59efa
    • Ross McIlroy's avatar
      Reland: [Compiler] Use CompilationCache for StreamedScript compilation. · 25427203
      Ross McIlroy authored
      Previously GetSharedFunctionInfoForStreamedScript didn't either check the
      compilation cache or put the result of compilation into the compilation
      cache. This would mean future compiles would need to re-parse / compile
      the same script even if the isolate had already seen it. This CL
      fixes this.
      
      Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile()
      for all script compiles even when loading from a cache.
      
      BUG=v8:5203
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Change-Id: I0a74c5b67bfaca5e50511d5f72da0ab53d8457f6
      Reviewed-on: https://chromium-review.googlesource.com/937724
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51594}
      25427203
  8. 20 Feb, 2018 1 commit
  9. 16 Feb, 2018 2 commits
  10. 08 Feb, 2018 1 commit
  11. 22 Jan, 2018 1 commit
  12. 12 Jan, 2018 1 commit
  13. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org
      TBR=neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
      Reviewed-on: https://chromium-review.googlesource.com/857593
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  14. 09 Jan, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored
      This reverts commit bf4cc9ee.
      
      Reason for revert: Breaks windows with msvc and linux with gcc
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
      
      Original change's description:
      > [esnext] load `iterator.next` only once at beginning of iteration
      > 
      > https://github.com/tc39/ecma262/pull/988 gained concensus during the
      > september 2017 TC39 meetings. This moves the load of the "next" method
      > to the very beginning of the iteration protocol, rather than during
      > each iteration step.
      > 
      > This impacts:
      > 
      > - yield*
      > - for-of loops
      > - spread arguments
      > - array spreads
      > 
      > In the v8 implementation, this also affects async iteration versions of
      > these things (the sole exception being the Async-From-Sync iterator,
      > which requires a few more changes to work with this, likely done in a
      > followup patch).
      > 
      > This change introduces a new AST node, ResolvedProperty, which can be used
      > as a callee by Call nodes to produce the same bytecode as Property calls,
      > without observably re-loading the property. This is used in several
      > AST-desugarings involving the iteration protocol.
      > 
      > BUG=v8:6861, v8:5699
      > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      > Reviewed-on: https://chromium-review.googlesource.com/687997
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50452}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
      
      Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6861, v8:5699
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      Reviewed-on: https://chromium-review.googlesource.com/687997
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee
  15. 18 Dec, 2017 1 commit
  16. 14 Dec, 2017 1 commit
  17. 12 Dec, 2017 4 commits
    • Georg Neis's avatar
      Reland "Fix "this" value in lazily-parsed module functions." · 585b39f5
      Georg Neis authored
      This is a reland of c3bd741e
      Original change's description:
      > Fix "this" value in lazily-parsed module functions.
      >
      > When preparsing top-level functions in a module, we didn't track
      > unresolved variables. Consequently, "this" ended up referencing
      > the global "this", which has the wrong value (in a module "this"
      > is supposed to be the undefined value).
      >
      > This patch fixes that. This also lets us stop forcing context
      > allocation of all variables in module scopes, which the patch
      > takes care of as well.
      >
      > Bug: chromium:791334
      > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      > Reviewed-on: https://chromium-review.googlesource.com/808938
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50025}
      
      TBR=adamk@chromium.org
      TBR=kozyatinskiy@chromium.org
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      
      Bug: chromium:791334
      Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec
      Reviewed-on: https://chromium-review.googlesource.com/822341
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50045}
      585b39f5
    • Michael Achenbach's avatar
      Revert "Fix "this" value in lazily-parsed module functions." · 62f09de9
      Michael Achenbach authored
      This reverts commit c3bd741e.
      
      Reason for revert: Breaks layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/20384
      
      Original change's description:
      > Fix "this" value in lazily-parsed module functions.
      > 
      > When preparsing top-level functions in a module, we didn't track
      > unresolved variables. Consequently, "this" ended up referencing
      > the global "this", which has the wrong value (in a module "this"
      > is supposed to be the undefined value).
      > 
      > This patch fixes that. This also lets us stop forcing context
      > allocation of all variables in module scopes, which the patch
      > takes care of as well.
      > 
      > Bug: chromium:791334
      > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      > Reviewed-on: https://chromium-review.googlesource.com/808938
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50025}
      
      TBR=adamk@chromium.org,marja@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
      
      Change-Id: I81f69334ed2ce104c00e6205d50001e4bdf07d15
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:791334
      Reviewed-on: https://chromium-review.googlesource.com/822258Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50036}
      62f09de9
    • Georg Neis's avatar
      Fix "this" value in lazily-parsed module functions. · c3bd741e
      Georg Neis authored
      When preparsing top-level functions in a module, we didn't track
      unresolved variables. Consequently, "this" ended up referencing
      the global "this", which has the wrong value (in a module "this"
      is supposed to be the undefined value).
      
      This patch fixes that. This also lets us stop forcing context
      allocation of all variables in module scopes, which the patch
      takes care of as well.
      
      Bug: chromium:791334
      Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      Reviewed-on: https://chromium-review.googlesource.com/808938Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50025}
      c3bd741e
    • Alexey Kozyatinskiy's avatar
      [inspector] do not capture hint if there is no break location · be3c2cdd
      Alexey Kozyatinskiy authored
      If we have several scripts with the same url (see many <script> tags in
      one page), then we try to set breakpoint only in script with given
      lineNumber inside and ignore all other scripts. We should follow the
      same logic when we capture hint for later breakpoint restore.
      
      R=yangguo@chromium.org
      
      Bug: none
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I44a332ac64f62ec9a0d24d5fe4688f8ced125e39
      Reviewed-on: https://chromium-review.googlesource.com/821053
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50019}
      be3c2cdd
  18. 06 Dec, 2017 1 commit
  19. 29 Nov, 2017 1 commit
  20. 23 Nov, 2017 2 commits
  21. 22 Nov, 2017 3 commits
    • Alexey Kozyatinskiy's avatar
      Reland [inspector] introduced stackTraceId and externalAsyncTask API · 885a5669
      Alexey Kozyatinskiy authored
      Sometimes we need to capture stack trace on one debugger and use it
      later as a parent stack on another debugger (e.g. worker.postMessage).
      
      This CL includes following addition to our protocol and v8-inspector.h:
        - added Runtime.StackTraceId, this id represents stack trace captured
          on debugger with given id,
        - protocol client can fetch Runtime.StackTrace by
          Runtime.StacKTraceId using Debugger.getStackTrace method,
        - externalParent field is added to Debugger.paused event, it may
          contain external parent stack trace,
        - V8Inspector::storeCurrentStackTrace captures current stack trace
          and returns V8StackTraceId for embedder this id can be used as
          argument for V8Inspector::externalAsyncTaskStarted and
          V8Inspector::externalAsyncTaskFinished method. Any async stack
          trace captured between these calls will get passed external stack
          trace as external parent. These methods are designed to be called
          on different debuggers. If async task is scheduled and started on
          one debugger user should continue to use asyncTask* API,
        - Debugger.enable methods returns unique debuggerId.
      
      TBR=dgozman@chromium.org,jgruber@chromium.org
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4
      Reviewed-on: https://chromium-review.googlesource.com/786274
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49591}
      885a5669
    • Clemens Hammacher's avatar
      Revert "[inspector] introduced stackTraceId and externalAsyncTask API" · 4379533c
      Clemens Hammacher authored
      This reverts commit 3a41b697.
      
      Reason for revert: Break msvc: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/250
      
      Original change's description:
      > [inspector] introduced stackTraceId and externalAsyncTask API
      > 
      > Sometimes we need to capture stack trace on one debugger and use it
      > later as a parent stack on another debugger (e.g. worker.postMessage).
      > 
      > This CL includes following addition to our protocol and v8-inspector.h:
      >   - added Runtime.StackTraceId, this id represents stack trace captured
      >     on debugger with given id,
      >   - protocol client can fetch Runtime.StackTrace by
      >     Runtime.StacKTraceId using Debugger.getStackTrace method,
      >   - externalParent field is added to Debugger.paused event, it may
      >     contain external parent stack trace,
      >   - V8Inspector::storeCurrentStackTrace captures current stack trace
      >     and returns V8StackTraceId for embedder this id can be used as
      >     argument for V8Inspector::externalAsyncTaskStarted and
      >     V8Inspector::externalAsyncTaskFinished method. Any async stack
      >     trace captured between these calls will get passed external stack
      >     trace as external parent. These methods are designed to be called
      >     on different debuggers. If async task is scheduled and started on
      >     one debugger user should continue to use asyncTask* API,
      >   - Debugger.enable methods returns unique debuggerId.
      > 
      > Bug: chromium:778796
      > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
      > Reviewed-on: https://chromium-review.googlesource.com/754183
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49582}
      
      TBR=dgozman@chromium.org,pfeldman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
      
      Change-Id: I9b52354fa0841e5148596cf594317f2e5fe508ea
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/786152Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49584}
      4379533c
    • Alexey Kozyatinskiy's avatar
      [inspector] introduced stackTraceId and externalAsyncTask API · 3a41b697
      Alexey Kozyatinskiy authored
      Sometimes we need to capture stack trace on one debugger and use it
      later as a parent stack on another debugger (e.g. worker.postMessage).
      
      This CL includes following addition to our protocol and v8-inspector.h:
        - added Runtime.StackTraceId, this id represents stack trace captured
          on debugger with given id,
        - protocol client can fetch Runtime.StackTrace by
          Runtime.StacKTraceId using Debugger.getStackTrace method,
        - externalParent field is added to Debugger.paused event, it may
          contain external parent stack trace,
        - V8Inspector::storeCurrentStackTrace captures current stack trace
          and returns V8StackTraceId for embedder this id can be used as
          argument for V8Inspector::externalAsyncTaskStarted and
          V8Inspector::externalAsyncTaskFinished method. Any async stack
          trace captured between these calls will get passed external stack
          trace as external parent. These methods are designed to be called
          on different debuggers. If async task is scheduled and started on
          one debugger user should continue to use asyncTask* API,
        - Debugger.enable methods returns unique debuggerId.
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539
      Reviewed-on: https://chromium-review.googlesource.com/754183Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49582}
      3a41b697
  22. 21 Nov, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] reworked async instrumentation for promises · ed9b2072
      Alexey Kozyatinskiy authored
      Old instrumentation was designed to collect promise creation stack and
      promise scheduled stack together. In DevTools for last 6 months we
      show only creation stack for promises. We got strong support from users
      for new model. Now we can drop support for scheduled stacks and
      simplify implementation.
      
      New promise instrumentation is straightforward:
      - we send kDebugPromiseThen when promise is created by .then call,
      - we send kDebugPromiseCatch when promise is created by .catch call,
      - we send kDebugWillHandle before chained callback and kDebugDidHandle
        after chained callback,
      - and we send separate kDebugAsyncFunctionPromiseCreated for internal
        promise inside async await function.
      
      Advantages:
      - we reduce amount of captured stacks (we do not capture stack for
        promise that constructed not by .then or .catch),
      - we can consider async task related to .then and .catch as one shot
        since chained callback is executed once,
      - on V8 side we can implement required instrumentation using only
        promise hooks,
      
      Disadvantage:
      - see await-promise test, sometimes scheduled stack was useful since we
        add catch handler in native code,
      
      Implementation details:
      - on kInit promise hook we need to figure out why promise was created.
        We analyze builtin functions until first user defined function on
        current stack. If there is kAsyncFunctionPromiseCreate function then
        we send kDebugAsyncFunctionPromiseCreated event. If there is
        kPromiseThen or kPromiseCatch then only if this function is bottom
        builtin function we send corresponded event to inspector. We need it
        because Promise.all internally calls .then and in this case we have
        Promise.all and Promise.then on stack at the same time and we do not
        need to report this internally created promise to inspector.
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47
      Reviewed-on: https://chromium-review.googlesource.com/765208
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49553}
      ed9b2072
  23. 08 Nov, 2017 1 commit
  24. 06 Nov, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] added new way to step into async task · 079c0fd8
      Alexey Kozyatinskiy authored
      It is preparation step for step-into-worker. There are few changes:
      - added breakOnAsyncCall flag for Debugger.stepInto. When flag is set
        and async task is scheduled before step-into finished, we pause
        execution with additional Debugger.paused event. This event contains
        additional scheduledAsyncTaskId field.
      - added Debugger.pauseOnAsyncTask. This method will pause execution as
        soon as given async task is started.
      
      This mechanism is replacement for Debugger.scheduleStepIntoAsync which
      can not be used between multiple targets.
      
      As result we can split async task scheduling in one target and
      requesting break for this async task running in another target.
      
      R=pfeldman@chromium.org
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I77be0c880d91253d333c54a23a4c084e7b8549e9
      Reviewed-on: https://chromium-review.googlesource.com/750071Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarPavel Feldman <pfeldman@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49127}
      079c0fd8
  25. 04 Nov, 2017 1 commit
  26. 23 Oct, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve this value for arrow function in scopes · a11b0d96
      Alexey Kozyatinskiy authored
      Currently we incorrectly show global object as arrow function receiver.
      With this CL:
      - if this is used inside of function we show correct this value,
      - if this is unused and V8 optimizes it out - we show undefined.
      
      Second is known issue which we should address separately.
      
      R=dgozman@chromium.org,yangguo@chromium.org
      
      Bug: chromium:552753
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Iac88a07fe622eb9b2f8af7ecbc4a32a56c8cdfaa
      Reviewed-on: https://chromium-review.googlesource.com/723840
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48839}
      a11b0d96
  27. 18 Oct, 2017 1 commit
  28. 16 Oct, 2017 1 commit