1. 23 Nov, 2017 3 commits
  2. 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
  3. 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
  4. 06 Nov, 2017 2 commits
  5. 04 Nov, 2017 1 commit
  6. 17 Oct, 2017 1 commit
  7. 07 Oct, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] provisional breakpoints for anonymous script · 83198829
      Alexey Kozyatinskiy authored
      Use case: anonymous script with sourceMappingUrl. User can set
      breakpoint in source with sourceUrl from sourceMap, we persist this
      breakpoint in DevTools and on page reload breakpoint should be restored
      correctly.
      
      Debugger.setBreakpointByUrl method provides capabilities to set
      provisional breakpoints and looks like best candidate for new "scriptHash"
      argument.
      
      I considered other options such as replacing scriptId with something
      more persistent like "script-hash:script-with-this-hash-number" but it
      looks more complicated and doesn't provide clear advantages.
      
      One pager: http://bit.ly/2wkRHnt
      
      R=pfeldman@chromium.org
      
      Bug: chromium:459499
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I0e2833fceffe6b04afac01d1a4522d6874b6067a
      Reviewed-on: https://chromium-review.googlesource.com/683597
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48357}
      83198829
  8. 27 Sep, 2017 1 commit
  9. 08 Sep, 2017 1 commit
  10. 07 Sep, 2017 1 commit
  11. 31 Aug, 2017 1 commit
  12. 29 Aug, 2017 2 commits
  13. 25 Aug, 2017 1 commit
  14. 23 Aug, 2017 2 commits
  15. 21 Aug, 2017 1 commit
  16. 15 Aug, 2017 1 commit
  17. 23 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Expose block coverage through inspector · 1541f422
      jgruber authored
      This piggy-backs on top of existing precise and best-effort coverage to expose
      block coverage through the inspector protocol.
      
      Coverage collection now implicitly reports block-granularity coverage when
      available.  A new 'isBlockCoverage' property on Inspector's FunctionCoverage
      type specifies the granularity of reported coverage.
      
      For now, only count-based block coverage is supported, but binary block
      coverage should follow soon.
      
      Support is still gated behind the --block-coverage flag.
      
      Bug: v8:6000
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I9c4d64e1d2a098e66178b3a68dcee800de0081af
      Reviewed-on: https://chromium-review.googlesource.com/532975
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46157}
      1541f422
  18. 12 Jun, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] introduced console.context · 701d79d0
      Alexey Kozyatinskiy authored
      console.context(name:string) method returns console instance, this console instance fully implements console interface (including fact that any method can be called without console as receiver).
      Protocol.Runtime.consoleAPICalled notification contains additional context:string field:
      - "anonymous#unique-id" for any method call on unnamed console context,
      - "name#unique-id" for any method call on named console context.
      
      console.count and console.timeEnd have context as a scope.
      console.clear clear all messages regardless on what context instance it was called.
      
      console calls is ~10% slower with this CL since we need to store and then fetch console_context_id and console_context_name from function object.
      We recently (in April) made console calls twice faster so 10% doesn't sound critical and existing of console.log call in hot code is problem by itself.
      
      R=pfeldman@chromium.org
      
      Bug: chromium:728767
      Change-Id: I5fc73216fb8b28bfe1e8c2c1b393ebfbe43cd02e
      Reviewed-on: https://chromium-review.googlesource.com/522128Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-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@{#45864}
      701d79d0
  19. 16 May, 2017 1 commit
  20. 24 Apr, 2017 1 commit
  21. 23 Mar, 2017 1 commit
    • yangguo's avatar
      [debug] introduce precise binary code coverage. · d71ef941
      yangguo authored
      With precise binary code coverage, the reported count is either 0 or 1.
      We only report 1 the first time we collect coverage data after the
      function has been executed.
      
      Since we do not care about the accurate execution count, we can optimize
      the function once it has been executed once.
      
      Also change best effort coverage to be implicitly binary.
      
      R=caseq@chromium.org, jgruber@chromium.org, pfeldman@chromium.org
      BUG=v8:5808
      
      Review-Url: https://codereview.chromium.org/2766573003
      Cr-Commit-Position: refs/heads/master@{#44074}
      d71ef941
  22. 22 Mar, 2017 1 commit
  23. 16 Mar, 2017 1 commit
  24. 10 Mar, 2017 1 commit
  25. 08 Mar, 2017 1 commit
  26. 07 Mar, 2017 1 commit
  27. 06 Mar, 2017 2 commits
  28. 27 Feb, 2017 1 commit
  29. 25 Feb, 2017 1 commit
  30. 22 Feb, 2017 1 commit
  31. 10 Feb, 2017 1 commit
  32. 09 Feb, 2017 1 commit