1. 17 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Decouple async event delegate instrumentation from PromiseHooks. · b46d5ffb
      Benedikt Meurer authored
      As described in https://crbug.com/1287476, the fact that the
      AsyncEventDelegate is currently implemented on top of the PromiseHooks
      causes performance problems and makes it difficult to reason about the
      exact (observed) semantics; this is because for this we intercept every
      JSPromise creation (via PromiseHook::kInit) and walk the synchronous
      stack at that point to see if we find one of Promise#then(),
      Promise#catch() or Promise#finally() on the stack. And if we do so, we
      report that to the AsyncEventDelegate (which is implemented in the
      inspector and will then do the async stack/stepping logic on top).
      
      This CL introduces dedicated instrumentation for Promise#then(), which
      is also called from Promise#catch() and Promise#finally(), and uses that
      instrumentation for the purpose of the AsyncEventDelegate. It also
      adjusts the stack walk to not always walk the full stack (which might
      lead to wrong results when calls to Promise#then(), which itself can
      call back into user JavaScript, are found deeper in the stack), but
      instead only check the top-most builtin frames and whatever user
      JavaScript frame is underneath it.
      
      On the standalone.js (from https://crbug.com/1287476#c1), when run with
      the DevTools default of maxDepth=200, we go from around 4.00ms to around
      0.36ms. For everything that does not call Promise#then() - either
      explicitly or implicitly - or `await`s, there's now no observable
      performance impact of turning on the AsyncEventDelegate.
      
      Bug: chromium:1280519
      Fixed: chromium:1287476
      Change-Id: I4911bed146381fc46cfeefb763d6dfc32e8f6071
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386379
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78640}
      b46d5ffb
  2. 14 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Consolidate promise stack runtime functions. · cfaf8957
      Benedikt Meurer authored
      Following up on https://crrev.com/c/3383775 I realized that we could
      just use the existing %DebugPopPromise and %DebugPushPromise runtime
      functions, which do exactly the same job as %DebugAsyncFunctionFinished
      and %DebugAsyncFunctionResumed, and are already used in other places of
      promise instrumentation.
      
      We can also remove %DebugAsyncFunctionEntered and utilize the logic in
      NewJSPromise() to deal with the various promise hooks, and otherwise go
      with %DebugPushPromise for the debugger side.
      
      Bug: chromium:1280519
      Change-Id: I79c77236f19c8783161c1eee36d2a16d52c60e82
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386382Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78626}
      cfaf8957
  3. 13 Jan, 2022 2 commits
    • Benedikt Meurer's avatar
      [async-await] Further simplify `await` and its instrumentation. · 302a5d20
      Benedikt Meurer authored
      Following up on https://crrev.com/c/3383775 we are now able to further
      simplify the implementation of `await` and its instrumentation (for both
      debugger and promise hooks), which aligns the implementation more
      closely with the spec text and removes a whole bunch of unnecessary
      code.
      
      This also moves the `await` instrumentation into runtime-debug.cc along
      with the other instrumentation methods for async functions.
      
      Bug: chromium:1280519, chromium:1277451, chromium:1246867
      Change-Id: I3fb543c76229091b502f3188da962784977158ab
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386597
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78610}
      302a5d20
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored
      This unifies and simplifies the way we instrument async functions for
      the purpose of async stack traces and async stepping. It does so while
      retaining the observable behavior on the inspector level (for now).
      
      Previously we'd mark the implicit promise of the async function object
      with the async task ID, and whenever we awaited, we'd copy the async
      task ID to the throwaway promise that is created by the `await`. This
      however made things unnecessarily interesting in the following regards:
      
      1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
      `AsyncFunctionFinished` events, coming from the throwaway promises,
      while the implicit promise is "done". This is especially confusing
      with rejection propagation and requires very complex stepping logic
      for async functions (after this CL it'll be possible to unify and
      simplify the stepping logic).
      2. We have to thread through the "can suspend" information from the
      Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
      to the async function instrumentation to decide whether to cancel the
      pending task when the async function finishes.
      
      This CL changes the instrumentation to only happen (non recurringly) for
      the throwaway promises allocated upon `await`. This solves both problems
      mentioned above, and works because upon the first `await` the stack
      captured for the throwaway promise will include the synchronous part as
      expected, while upon later `await`s the synchronous part will be empty
      and the asynchronous part will be the stack captured for the previous
      throwaway promise (and the V8Debugger automatically short circuits
      stacks with empty synchronous part).
      
      Bug: chromium:1280519, chromium:1277451, chromium:1246867
      Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
  4. 03 Dec, 2021 1 commit
  5. 02 Dec, 2021 1 commit
  6. 17 Sep, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Make `ArrayBuffer.[[ArrayBufferData]]` deterministic. · 833b3c96
      Benedikt Meurer authored
      Previously the internal `[[ArrayBufferData]]` property for `ArrayBuffer`
      objects reported by the inspector (and used by the DevTools front-end to
      identify `ArrayBuffer`s and `WebAssembly.Memory`s using the same backing
      store) simply contained a hex string representation of the backing store
      pointer. However that unnecessarily leaks internal addresses and more
      importantly is not deterministic, which complicates tests (just blew up
      on layout tests).
      
      This CL introduces an automatically incremented `BackingStore::id()`,
      which is used instead now and is deterministic.
      
      Bug: chromium:1199701, chromium:1163802, chromium:1249961
      Change-Id: I8ee47009cd825cfdbe00230f617c87c90508ab2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162144
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76893}
      833b3c96
  7. 28 Jul, 2021 1 commit
  8. 23 Jul, 2021 2 commits
  9. 18 Jun, 2021 1 commit
  10. 01 Jun, 2021 1 commit
  11. 20 May, 2021 1 commit
  12. 29 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Remove "Restart frame" feature. · 93f85699
      Benedikt Meurer authored
      The "Restart frame" feature was implemented as part of LiveEdit and
      primarily used to support LiveEdit of active functions, but that was
      previously disabled as part of https://crrev.com/c/2846892 because it's
      too brittle and causes crashes when using seemingly unrelated features.
      The "Restart frame" feature was also available as a context menu item
      separately in the DevTools front-end, but that was also already removed
      as part of https://crrev.com/c/2854681 earlier. So all uses are gone
      now.
      
      This change works by marking Debugger.restartFrame as deprecated and
      having it respond with a ServerError all the time. It thus allows us to
      remove a whole bunch of machinery that was essentially just put in
      various places to support the restart_fp_ magic. In particular the
      debugger no longer needs any machine specific builtins now.
      
      Bug: chromium:1195927
      Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
      Fixed: chromium:1203606
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74276}
      93f85699
  13. 28 Apr, 2021 2 commits
    • Benedikt Meurer's avatar
      [debug] Disallow LiveEdit of active frames. · 53fc4807
      Benedikt Meurer authored
      Previously we'd allow to replace the source of functions that are on the
      current execution stack under certain conditions, but this has resulted
      in an endless stream of bugs due to weird edge cases, and so we're now
      limiting LiveEdit to functions that don't have any activation (including
      not a suspended generator / async function activation).
      
      We might eventually add the ability to LiveEdit functions with
      activations and have them "upgrade upon next invocation", but that
      doesn't seem to be an extremely important use case right now.
      
      Fixed: chromium:1195927
      Change-Id: I87a45ba4d0ddcfbf867bd4e73738d76b2d789e04
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846892
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74249}
      53fc4807
    • Jakob Gruber's avatar
      [snapshot] Fix the Memory.json benchmark · f5594f50
      Jakob Gruber authored
      .. which traces various stats (time, memory) related to the snapshot.
      Due to various flag shuffles, it was broken as of Oct 2020, with some
      line items reporting constant 0.
      
      This also refactors --profile-deserialization and
      --serialization-statistics s.t. the former only reports
      deserialization times and the latter reports memory. Memory.json now
      passes both flags.
      
      Change-Id: I7dacbbbe9f7a667e0802d0f7a44703dc34524a4e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854742
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74241}
      f5594f50
  14. 12 Apr, 2021 1 commit
  15. 09 Apr, 2021 2 commits
  16. 17 Mar, 2021 1 commit
  17. 16 Mar, 2021 1 commit
  18. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored
      This is a reland of 80f5dfda. A condition
      in pipeline.cc was inverted, which lead to a CSA verifier error.
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      TBR=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored
      This reverts commit 80f5dfda.
      
      Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      Bug: v8:11238
      Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored
      This is the biggest chunk, including
      - all of src/wasm,
      - torque file for wasm objects,
      - torque file for wasm builtins,
      - wasm builtins,
      - wasm runtime functions,
      - int64 lowering,
      - simd scala lowering,
      - WasmGraphBuilder (TF graph construction for wasm),
      - wasm frame types,
      - wasm interrupts,
      - the JSWasmCall opcode,
      - wasm backing store allocation.
      
      Those components are all recursively entangled, so I found no way to
      split this change up further.
      
      Some includes that were recursively included by wasm headers needed to
      be added explicitly now.
      
      backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      because it only tests wasm backing stores. This file is excluded from
      no-wasm builds then.
      
      R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      
      Bug: v8:11238
      Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  19. 02 Mar, 2021 1 commit
  20. 24 Feb, 2021 1 commit
  21. 09 Feb, 2021 1 commit
  22. 28 Jan, 2021 1 commit
  23. 12 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector][wasm] Improve Scope view and instance preview. · a23adbbc
      Benedikt Meurer authored
      This adds the following internal properties to `WasmInstanceObject`
      values in DevTools:
      
       - `[[Module]]` pointing to the `WasmModuleObject`, allowing the
         developer to find the module to an instance no matter where in
         DevTools front-end the instance is inspected.
       - `[[Functions]]`, `[[Globals]]`, `[[Memories]]`, and `[[Tables]]`
         are shown (when they aren't empty), allowing developers to inspect
         the entities within an instance no matter where in DevTools front-end
         it's inspected.
      
      This also updates the _Module_ scope for Wasm frames to show the entity
      containers (`functions`, `globals`, `memories` and `tables`) in addition
      to the `instance` and `module` to make it easier accessible (fewer
      clicks to get there), but also to align it better with the _Add property
      path to Watch_ and _Copy property path_ features (since exactly the same
      names are exposed via Debug Evaluate on Wasm frames).
      
      ```
      > Stack
      > Locals
      v Module
        > module
        > instance
        > functions
        > globals
        > memories
        > tables
      ```
      
      Drive-by-fix: Move GetWasmModuleObjectInternalProperties() logic into
      debug-wasm-support.cc
      
      Screenshot: https://imgur.com/ksEHG2I.png
      Doc: http://bit.ly/devtools-wasm-entities
      Fixed: chromium:1165294
      Bug: chromium:1071432, chromium:1164241, chromium:1165304
      Change-Id: Ia88fb2705287c79988ff2b432e4a33ac34e098f5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622912Reviewed-by: 's avatarPhilip Pfaffe <pfaffe@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72042}
      a23adbbc
  24. 11 Jan, 2021 1 commit
  25. 05 Jan, 2021 1 commit
  26. 29 Dec, 2020 3 commits
    • Benedikt Meurer's avatar
      [wasm][debug] Expose instance and module instead of imports / exports. · ad42f966
      Benedikt Meurer authored
      The "imports" and "exports" that were exposed on WebAssembly frames via
      Debug-Evaluate aren't useful for the DWARF C/C++ extension (and likely
      not for any other language extension), since they only expose static
      information that's easily available (upfront) by reading the Wasm wire
      bytes.
      
      In fact, there are already standardized functions in the WebAssembly
      specification, namely `WebAssembly.Module.imports(module)` and
      `WebAssembly.Module.exports(module)`, which yield static information
      about the imports and exports of a Wasm module.
      
      So instead of exposing special, non-standard "imports" and "exports", we
      now instead expose both the "instance" and the "module" objects via both
      the Debug Proxy and the Scope view, and also add internal [[Exports]]
      and [[Imports]] properties to WasmModuleObject, which under the hood use
      the standard methods mentioned above.
      
      Fixed: chromium:1162069
      Bug: chromium:1071432, chromium:1083146
      Screenshot: https://imgur.com/lcaW2jL.png
      Doc: https://docs.google.com/document/d/1rqbu0jKTl3q_xCxLnKzkjGXWEsHnJ9aERVhKV9RNDgE#bookmark=id.925bb2qgou38
      Change-Id: Ie27e55bb08ea5f90493c57375bf2b48dfb11a4d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606050
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71893}
      ad42f966
    • Benedikt Meurer's avatar
      [debug] Make JSArrayBuffer (pre)views into internal properties. · 2cab7ae9
      Benedikt Meurer authored
      For JSArrayBuffer instances (which map to both v8::ArrayBuffer and
      v8::SharedArrayBuffer), we add a couple of synthetic views to its
      ValueMirror to make it easy for developers to peak into the contents of
      the JSArrayBuffer. These were previously real properties, but that's
      just wrong (both intuitively and semantically), and they should instead
      be internal properties.
      
      Drive-by-fix: The [[IsDetached]] internal property should only be shown
      on actually detached JSArrayBuffer's to reduce visual clutter. And for
      detached JSArrayBuffers creating views on them throws TypeErrors per
      specification, so we shouldn't attempt to display views on them.
      
      Bug: v8:9308, chromium:1162229
      Change-Id: Ia006de7873ca4b27aae7d00d46e1b69d2e326449
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606047
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71892}
      2cab7ae9
    • Benedikt Meurer's avatar
      [debug] Remove dead %GetHeapUsage() runtime function. · 2a813525
      Benedikt Meurer authored
      Bug: chromium:116229
      Change-Id: I16e185c2156dd7ba812f7d484c2e281febfa3635
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606048
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71891}
      2a813525
  27. 17 Dec, 2020 1 commit
  28. 27 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      [code] Extend comments, use better terms to describe metadata · 23ba0667
      Jakob Gruber authored
      This addresses comments from [0] by extending comments to also
      describe embedded builtins in code.h, and by improving language
      around various meaning of 'metadata':
      
      - The Code object's metadata section is still called 'metadata'.
      - The embedded blob's table of layout descriptions for builtins is
        now called 'layout descriptions'.
      - The embedded blob's data section (containing hashes and layout
        descriptions) is now called 'data' section.
      
      [0] chromium-review.googlesource.com/c/v8/v8/+/2491025
      
      Bug: v8:11036
      Change-Id: Ibe84fddb9784cc5d3b66482612dcdb7a2e8d14ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501284
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70793}
      23ba0667
  29. 24 Jul, 2020 1 commit
    • Benedikt Meurer's avatar
      [inspector] Add internal property to identify detached ArrayBuffers. · b886e153
      Benedikt Meurer authored
      This adds an internal property [[IsDetached]] to the inspector preview
      of ArrayBuffer instances, which indicates whether the ArrayBuffer was
      detached (i.e. transfered via `postMessage`). Previously it was rather
      impossible to tell whether an ArrayBuffer was detached, you had to know
      that V8 violates the ECMAScript specification and simply sets the
      byteLength accessor to 0 upon detaching an ArrayBuffer (but even then it
      was still impossible to tell whether that ArrayBuffer wasn't simply an
      empty one from the get go).
      
      Before: https://imgur.com/UcOF83c
      After: https://imgur.com/WjmTehZ
      
      Fixed: chromium:1109102
      Change-Id: I8fb6e2be2fbfe5c62b05dc9d2a0f18378eb4de6c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316075
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69034}
      b886e153
  30. 22 Jul, 2020 1 commit
  31. 02 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Support multi-threaded breakpoints · 5fcb414a
      Clemens Backes authored
      This adds support for multiple isolates sharing the same module but
      setting different breakpoints. This is simulated by having a debugger
      test that runs in the "--isolates" variant, i.e. two isolates running
      the same test at the same time. Both isolates will set and remove
      breakpoints.
      
      The DebugInfo will keep a separate list of breakpoints per isolate, and
      when recompiling a function for debugging it will respect all
      breakpoints in all isolates.
      In order to ensure consistency if multiple isolates are setting or
      removing breakpoints simultaneously, we go back to a more coarse-grained
      locking scheme, where the DebugInfo lock is held while re-compiling
      Liftoff functions.
      
      While recompilation will install the code in the module-global code
      table and jump table (and hence all isolates will use it for future
      calls), only the stack of the requesting isolate is rewritten to
      immediately use new code. This is OK, because other isolates are not
      interested in the new breakpoint(s) anyway.
      On {SetBreakpoint}, we always need to rewrite the stack of the
      requesting isolate though, even if the breakpoint was set before by
      another isolate.
      
      Drive-by: Some fixes in SharedFunctionInfo in order to support setting
      breakpoints via the Debug mirror.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Change-Id: If659afb273260fc5e8124b4b617fb4322de473c7
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218059Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68096}
      5fcb414a
  32. 15 May, 2020 1 commit