1. 25 Nov, 2018 1 commit
  2. 12 Nov, 2018 1 commit
  3. 29 Oct, 2018 1 commit
  4. 22 Oct, 2018 1 commit
  5. 28 Sep, 2018 1 commit
  6. 18 Sep, 2018 1 commit
  7. 17 Sep, 2018 2 commits
  8. 13 Aug, 2018 1 commit
  9. 03 Aug, 2018 1 commit
    • Ben Newman's avatar
      [debug] Fully implement Debug::ArchiveDebug and Debug::RestoreDebug. · a8f68691
      Ben Newman authored
      I have a project that embeds V8 and uses a single `Isolate` from multiple
      threads. The program runs just fine, but sometimes the inspector doesn't
      stop on the correct line after stepping over a statement that switches
      threads behind the scenes, even though the original thread is restored by
      the time the next statement is executed.
      
      After some digging, I discovered that the `Debug::ArchiveDebug` and
      `Debug::RestoreDebug` methods, which should be responsible for
      saving/restoring this `ThreadLocal` information when switching threads,
      currently don't do anything.
      
      This commit implements those methods using MemCopy, in the style of other
      Archive/Restore methods in the V8 codebase.
      
      Related: https://groups.google.com/forum/#!topic/v8-users/_Qf2rwljRk8
      
      Note: I believe my employer, Meteor Development Group, has previously
      signed the CLA using the group email address google-contrib@meteor.com.
      
      R=yangguo@chromium.org,jgruber@chromium.org
      CC=info@bnoordhuis.nl
      
      Bug: v8:7230
      Change-Id: Id517c873eb81cd53f7216c7efd441b956cf7f943
      Reviewed-on: https://chromium-review.googlesource.com/833260
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54902}
      a8f68691
  10. 23 Jul, 2018 1 commit
  11. 05 Jul, 2018 2 commits
  12. 26 Jun, 2018 1 commit
  13. 23 Jun, 2018 1 commit
  14. 22 Jun, 2018 1 commit
  15. 18 Jun, 2018 1 commit
  16. 03 Jun, 2018 1 commit
  17. 31 May, 2018 1 commit
  18. 30 May, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] use interrupt for pause only as last resort · 6d87d957
      Alexey Kozyatinskiy authored
      With this CL we use interrupt for pause in two cases:
      - when we process Debugger.pause on interruption,
      - when we would like to break as soon as possible after OOM.
      In all other cases, e.g. for async step into we use break
      on function call by calling StepIn debugger action.
      
      In mentioned cases we should not actually use interrupt as well:
      - Debugger.pause in this case scheduled using interrupt and we
        may just break right now without requesting another interrupt,
        unfortunately blink side is not ready,
      - we should use more reliable way to break right after near OOM
        callback, otherwise we can get this callback, increase limit,
        request break on next interrupt, before interrupt get another
        huge memory allocation and crash.
      
      There are couple advantages:
      - we get much better break locations for async stepping
        (see inspector tests expectations),
      - we can remove DEBUG_BREAK interruption
        (it should speedup blackboxing with async tasks, see
        removed todo in debug.cc for details)
      - it is required preparation step for async step out,
        (see https://chromium-review.googlesource.com/c/v8/v8/+/1054618)
      
      Bug: v8:7753
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Iabd7627dbffa9a0eab1736064caf589d02591926
      Reviewed-on: https://chromium-review.googlesource.com/1054155
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53439}
      6d87d957
  19. 08 May, 2018 1 commit
  20. 17 Apr, 2018 1 commit
    • Ingvar Stepanyan's avatar
      Report late-bound scripts to the debugger · 1dcd1c9f
      Ingvar Stepanyan authored
      Previously, if an unbound script was created in a non-inspected context,
      but later bound to an inspected one, it never appeared in the
      debugger sources.
      
      After this change `OnAfterCompile` will be invoked not on the original
      script compilation, but when it's actually bound to a context for
      execution, which means `Debugger.scriptParsed` will be now sent to the
      inspector even for such precompiled scripts.
      
      R=jgruber@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org
      
      Bug: v8:7654
      Change-Id: Ice13312e425903fb2baf14edab5c566d649a6438
      Reviewed-on: https://chromium-review.googlesource.com/1013581Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52652}
      1dcd1c9f
  21. 11 Apr, 2018 1 commit
  22. 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
  23. 04 Apr, 2018 2 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
  24. 28 Mar, 2018 1 commit
  25. 27 Mar, 2018 1 commit
    • Ulan Degenbaev's avatar
      [heap,api] Introduce near-heap-limit callbacks. · 84a80e10
      Ulan Degenbaev authored
      The embedder can get notification when V8 heap size approaches the heap limit
      and can extend the heap limit if needed using
      - v8::Isolate::AddNearHeapLimitCallback
      - v8::Isolate::RemoveNearHeapLimitCallback
      
      This generalizes the exiting v8::debug::SetOutOfMemoryCallback API.
      
      Bug: chromium:824214
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ia444cb7efb6fe85c57fa3785e8fd1d8b654a5224
      Reviewed-on: https://chromium-review.googlesource.com/979447
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52238}
      84a80e10
  26. 26 Mar, 2018 1 commit
  27. 22 Mar, 2018 1 commit
  28. 21 Mar, 2018 1 commit
  29. 16 Mar, 2018 1 commit
  30. 12 Mar, 2018 1 commit
  31. 09 Mar, 2018 1 commit
  32. 08 Mar, 2018 3 commits
  33. 26 Feb, 2018 1 commit
  34. 23 Feb, 2018 1 commit
  35. 22 Feb, 2018 1 commit