A couple of customers have asked about using devtools to get information
about temporary allocations, with the goal of reducing GC time and/or
peak memory usage. Currently, the sampling heap profiler reports only
objects which are still alive at the end of the profiling session. In
this change, I propose adding configuration options when starting the
sampling heap profiler so that it can optionally include information
about objects which were discarded by the GC before the end of the
profiling session. A user could run the sampling heap profiler in
several different modes depending on their goals:
1. To find memory leaks or determine which functions contribute most to
steady-state memory consumption, the current default mode is best.
2. To find functions which cause large temporary memory spikes or large
GC pauses, the user can request data about both live objects and
those collected by major GC.
3. To tune for minimal GC activity in latency-sensitive applications
like real-time audio processing, the user can request data about
every allocation, including objects collected by major or minor GC.
4. I'm not sure why anybody would want data about objects collected by
minor GC and not objects collected by major GC, but it's also a valid
flags combination.
Change-Id: If55d5965a1de04fed3ae640a02ca369723f64fdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3868522
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#83202}
The DevTools frontend doesn't want the Wasm module's understanding of
function body offsets (i.e. including locals), but the ranges of
offsets where breakpoints can be set (i.e. only where instructions are).
This patch adjusts the reported offsets accordingly.
A consequence is that we have to report full (start,end) pairs for each
function, instead of being able to dedupe end1==start2 etc.
Bug: v8:12917
Change-Id: I0c7d2d96435cdac2c4553647b7bcc8783bc1798b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780526
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81887}
Thic CL adds a CDP API skeleton that will be used to disassemble WASM
modules using V8's new disassembler.
Bug: v8:12917, chromium:1325626
Change-Id: I4ca81aca923e9716653cd90367e5fad319483aae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721381
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81809}
This is a reland of commit dac6155649
This is a straight-up reland with no changes, because:
1) The failure doesn't reproduce locally
2) The failing flaky test that triggered the revert is not related
to the code modified by this CL and should (in theory) not be
impacted.
Original change's description:
> [inspector] Allow Debugger.setScriptSource to edit top-most function
>
> This CL adds a new boolean flag on the Debugger.setScriptSource CDP
> method that gets piped all the way through to the live-edit mechanism.
> The new flag enables live-editing of the top-most function while
> paused.
>
> The CL adds a couple of tests that cover the new core use cases for
> this flag.
>
> R=jarin@chromium.org
>
> Bug: chromium:1334484
> Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81127}
Bug: chromium:1334484
Change-Id: I9a9bf7e03d81c86adb4819b9756dd9afcf6fa021
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3706398
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81171}
This reverts commit dac6155649.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/9288/overview
Original change's description:
> [inspector] Allow Debugger.setScriptSource to edit top-most function
>
> This CL adds a new boolean flag on the Debugger.setScriptSource CDP
> method that gets piped all the way through to the live-edit mechanism.
> The new flag enables live-editing of the top-most function while
> paused.
>
> The CL adds a couple of tests that cover the new core use cases for
> this flag.
>
> R=jarin@chromium.org
>
> Bug: chromium:1334484
> Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81127}
Bug: chromium:1334484
Change-Id: I165269d6c1b001b516f10ae3716ffb57b675ab39
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3705378
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Owners-Override: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81130}
This CL adds a new boolean flag on the Debugger.setScriptSource CDP
method that gets piped all the way through to the live-edit mechanism.
The new flag enables live-editing of the top-most function while
paused.
The CL adds a couple of tests that cover the new core use cases for
this flag.
R=jarin@chromium.org
Bug: chromium:1334484
Change-Id: I12fec591b2b6550d89748714620e629548e1b9c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695354
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81127}
This CL introduces a new `status` enum returned by setScriptSource.
We'll use the information in the DevTools frontend to show more
meaningful error messages as well as disambiguate compilation errors
from failed live edits.
Drive-by: Deprecate the sync and async stack traces in the result.
Currently `setScriptSource` is guaranteed to stay paused so there
is no need to send along the same information from the
preceeding `Debugger.paused` event.
In the future we will restart the top-most frame once we allow
the top-most frame to be edited. In that case the inspector
fires Debugger.resumed + Debugger.paused events following the
live edit also making the info returned here superfluous.
R=jarin@chromium.org
Bug: chromium:1334484
Change-Id: I4226491caed72013a00927273c523213d797a766
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3691850
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81031}
This is a reland of commit 8278cb5015
The reland adds the RestartFrameTrampoline to the list of
builtins that the deoptimizer is allowed to return from for
control flow integrity.
Original change's description:
> [inspector] Re-enable Debugger#restartFrame
>
> Doc: https://bit.ly/revive-restart-frame
>
> This CL "undeprecates" Debugger#restartFrame and adds a new optional
> "mode" parameter for back-wards compatibility. Moreover, the return
> values are all deprecated. They were never actually used in the
> DevTools frontend and the same information is available from the
> Debugger#paused event that fires once execution stops at the
> beginning of the restarted function.
>
> The CL also re-baselines all the restart-frame inspector tests that
> now run successfully.
>
> R=bmeurer@chromium.org, kimanh@chromium.org
>
> Bug: chromium:1303521
> Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80491}
Bug: chromium:1303521
Change-Id: I13e2f8b5011795a38e541310622b8333a3d08049
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644624
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80534}
This reverts commit 8278cb5015.
Reason for revert: breaking https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/10778/overview
Original change's description:
> [inspector] Re-enable Debugger#restartFrame
>
> Doc: https://bit.ly/revive-restart-frame
>
> This CL "undeprecates" Debugger#restartFrame and adds a new optional
> "mode" parameter for back-wards compatibility. Moreover, the return
> values are all deprecated. They were never actually used in the
> DevTools frontend and the same information is available from the
> Debugger#paused event that fires once execution stops at the
> beginning of the restarted function.
>
> The CL also re-baselines all the restart-frame inspector tests that
> now run successfully.
>
> R=bmeurer@chromium.org, kimanh@chromium.org
>
> Bug: chromium:1303521
> Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80491}
Bug: chromium:1303521
Change-Id: Ibc33328c31a4b6ea736d07ce5e5ee109039eec8b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3645767
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80495}
Doc: https://bit.ly/revive-restart-frame
This CL "undeprecates" Debugger#restartFrame and adds a new optional
"mode" parameter for back-wards compatibility. Moreover, the return
values are all deprecated. They were never actually used in the
DevTools frontend and the same information is available from the
Debugger#paused event that fires once execution stops at the
beginning of the restarted function.
The CL also re-baselines all the restart-frame inspector tests that
now run successfully.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80491}
Deprecate the existing parameter to treat global objects as roots as
this is implied by exposing internals.
Bug: chromium:1321620
Change-Id: I73a8124d63f87599dee7080980844c418eb3b5e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3637797
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80456}
This change adds support for computing SHA-256 hashes in the stack
output of errors by adding a function to the prototype of the
`CallSite` object, passed to `Error.prepareStackTrace`. Additionally,
it updates the `hash` property from `Debugger.scriptParsed` and
`Debugger.scriptFailedToParse` to be SHA-256 instead of the
proprietary hash it is today.
It is intended to be an advancement in indexing source maps to
support improved tooling, especially for post-hoc or in-production
diagnostics scenarios.
The explainer can be found here:
https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing
Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80320}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds a new optional flag `canBeRestarted` to every call frame
in Debugger.paused events. As the name suggests, the flag indicates
whether we can restart a particular frame through Debugger.restartFrame
once implemented.
We are not able to safely restart all frames:
* We don't support WASM frames
* We don't support frames where resumable functions (async fns,
generators) and embedder C++ frames are between the top-most
frame and the to-be-restarted frame.
Note that from a CDP perspective the flag doesn't actually guarantee
a successful restart. CDP clients can issue
CDP commands between the Debugger.paused event and before a user
decides to restart a frame, which can potentially mess
with the stack.
The `canBeRestarted` flag tests are folded into the
Debugger.restartFrame tests. As the feature is not yet fully
implemented we short-circuit most of the tests for now and only
run them up until the first Debugger.restartFrame call fails
(except "fails-for-resumables.js").
This means the tests exercise the `canBeRestarted` flag, but not
the restarting functionality itself.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I01ab46dc3557ab8383960969fbe03e00604cc5e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596160
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80046}
1. Added `generateWebDriverValue` flag to `Runtime.evaluate` and `Runtime.callFunctionOn`.
2. Added `webDriverValue` field to `RemoteObject`, and set it in case of the `generateWebDriverValue` flag was set.
3. Added virtual method `bidiSerialize` to allow embedder-implemented serialization (like in https://crrev.com/c/3472491).
4. Implemented V8 serialization in a separate class `V8WebDriverSerializer`.
5. Hardcode `max_depth=1`.
6. Added tests.
Not implemented yet:
1. `objectId`.
2. Test of embedder-implemented serialization.
Tested automatically by:
```
python3 tools/run-tests.py --outdir out/foo inspector/runtime/add-web-driver-value
```
Naming to be discussed. Suggestions are very welcome.
Design doc: http://go/bidi-serialization
Change-Id: Ib35ed8ff58e40b3304423cc2139050136d844e2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472077
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Maksim Sadym <sadym@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79922}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. To help in this case, this CL introduces a new
CDP method "Runtime#getExceptionDetails" that behaves exactly as
advertised: It provides a populated "ExceptionDetails" structure
from a JS Error object.
R=bmeurer@chromium.org
Doc: https://bit.ly/runtime-get-exception-details
Bug: chromium:1278650
Change-Id: I084be10c1d852d3b7cac8d88e7f820e867be4722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337258
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78676}
This is the first step towards moving away from sending `url` with every
call frame when emitting the `Debugger.paused` event.
Bug: chromium:1270316, chromium:1271078
Change-Id: I2f57f21e15bf908ffb53f5c7b5862d3efa329c86
Doc: https://bit.ly/devtools-debugger-callframe-url
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344946
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78392}
This introduces a new, optional `nonIndexedPropertiesOnly` flag to the
`Runtime.getProperties` inspector request, which tells the inspector to
only report properties whose name is not an (typed) array index. This is
to support retrieving all properties except for the indexed ones when
the DevTools front-end decides to use the array bucketing mechanism.
Previously the DevTools front-end had some quite complicated logic in
place to simulate this via injected JavaScript, but that logic didn't
pick up internal properties and was also interfering with the inherited
accessor mechanism. With this new flag, it's straight-forward to
implement the correct behavior in the DevTools front-end.
The corresponding devtools-frontend CL is https://crrev.com/c/3099011.
Before: https://imgur.com/hMX6vaV.png
After: https://imgur.com/MGgiuJQ.png
Bug: chromium:1199701
Change-Id: Iacbe9756ed8a2e6982efaebe1e7c606d37c05379
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099686
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76360}
This reverts commit 91c8be9599.
RCS should not be exposed through the API or the inspector protocol as
they are meant as an internal debugging feature.
The only regularly tested and supported way is through chrome-tracing.
Given that this was used mostly for an experiment to analyse chrome's
performance, we can use pprof support as a replacement.
Original change's description:
> [DevTools] Implemented DevTools protocol API to retrieve V8 RunTime Call Stats.
>
> The new APIs are:
> enableRuntimeCallStats
> disableRuntimeCallStats
> getRuntimeCallStats
>
> The RunTime Call Stats are collected per isolate.
>
> Change-Id: I7e520e2c866288aa9f9dc74f12572abedf0d3ac8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881601
> Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64784}
Change-Id: Ia7575436e97d3420dd7e68414d89477e6a86bb05
Bug: v8:11395
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998585
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76297}
This properly threads through the `executionContextId` to the request
reported to the DevTools front-end, similarly to how we already report
the `executionContextId` as part of `Runtime.bindingCalled`.
Bug: chromium:1231521
Change-Id: I0a003041aedd8ec661d1b07cdddbcd1f2866a99f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3046187
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75875}
In order to implement eager (side effect free) evaluation of arbitrary
accessor properties correctly, we need the ability to call getters while
guaranteeing that we don't trigger side effects. This is accomplished by
adding a `throwOnSideEffect` flag to the `Runtime.callFunctionOn` API,
similar to what's already available with the `Runtime.evaluate` and the
`Debugger.evaluateOnCallFrame` APIs.
Bug: chromium:1076820, chromium:1119900, chromium:1222114
Change-Id: If2d6c51376669cbc71a9dd3c79403d24d62aee43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001360
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75556}
This interface allows associating meta information to
exceptions. This meta information can be used by debugging
tools, like DevTools, to learn about e.g. a network request
or a DevTools issue that is associated with the exception.
To do so the inspector client (i.e. embedder) has to provide
the data.
Bug: chromium:1213393
Change-Id: Ia86221f4f04b21024d592bafb2f74886ead8a6a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928496
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74909}
Based on an analysis of auto-generated code, based on
browser_protocol.pdl and js_protocol.pdl:
https://goreportcard.com/report/github.com/daabr/chrome-vision#misspell
Bug: chromium:1213460
Change-Id: Ib96b2d2700d0bf1ac90e88accd0bc15eccbb9d7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848874
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74810}
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/+/2854750
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74276}
`exectionContextId` parameter in Runtime.addBinding is not working
correctly and does not have a practical use case. Therefore,
deprecating it in favour of the `executionContextName` parameter that
better serves the purpose of exposing bindings to isolated worlds. We
expect most users to be able to migrate to `executionContextName`.
Bug: chromium:1169639
Change-Id: Ic37cefa6a62501c7e903923f1f9c0da7e51326c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844652
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74137}
- represent smis as fake heap numbers
- numbers nodes (both smi and heap numbers) reference a child node whose
name is "value" and whose entry is the string representation of that
number
That feature is disabled by default, and can be enabled by passing
captureNumericValue: true when calling HeapProfiler.takeHeapSnapshot
This patch slightly refactors some functions that operate on "essential
objects". We now check that the object is essential before trying to
create the entry. Otherwise, we would end up with smi objects created,
but not referenced anywhere.
Design doc:
https://docs.google.com/document/d/1Qh1zxyn0SS5wzJzitD6ecBJTdFbQkJogSMwxDRsn44o/edit
Change-Id: Ibbe6e79a54c4f9eace72bc0a0ccb622a97698e00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806747
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Arnaud Renevier <arenevier@fb.com>
Cr-Commit-Position: refs/heads/master@{#73985}
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now
represented as objects instead of holding the (primitive) values
directly, and SIMD128 values are no longer represented as Uint8Arrays.
The DWARF extension has been prepared for this breaking change.
The new `WasmValue` comes with `type` and `value` properties that hold
its contents. The motivation here is that this is a more extensible
approach. In case of SIMD128, the `value` property holds the canonical
string representation, which has the additional advantage that these
values can be compared with `===` (and `==`).
This partially reverts https://crrev.com/c/2614428, the main difference
here being that WasmValue is now a proper JSObject that can be exposed
on the DebugEvaluate proxy API.
Screenshot: https://imgur.com/rcahNKM.png
Bug: chromium:1170282, chromium:1071432, chromium:1159402
Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72570}
Previously we had introduced a special `v8::internal::WasmValue` type
which we used to expose Wasm values to the Scope view in Chromium
DevTools. The problem however is that these values cannot be exposed to
JavaScript (and in particular not to Debug Evaluate), which means that
particularly for v128 and i64 we have inconsistent representations
across the various parts of DevTools.
This change removes the `wasm` type from the RemoteObject and all the
adjacent logic, and paves the way for a uniform representation of Wasm
values throughout DevTools. For i64 we will simply use BigInt
consistently everywhere, and for i32, f32 and f64 we'll just use Number.
For externref we will represent the values as-is directly. For v128
values we currently use a Uint8Array, but will introduce a dedicated
WasmSimd128 class in a follow-up CL.
Bug: chromium:1071432
Fixed: chromium:1159402
Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71962}
Note that the `wasm` type and it's subtypes will be removed soon, so we
don't need to synchronize them.
Fixed: chromium:1162930
Change-Id: I8549679cbe53a1e50e98acedf8547dc09c20ad27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613036
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71950}
With https://crrev.com/c/2087396 we introduced a new CDP method
`Debugger.executeWasmEvaluator()`, which we originally intended
to use as the foundation for Debug-Evaluate on Wasm frames.
However in the process of prototyping we learned that it is too
costly and too inefficient to use WebAssembly modules here, and
we switched to regular Debug-Evaluate with JavaScript instead
(with a special debug proxy exposed that allows JavaScript to
peak into the Wasm frame), since JavaScript is better suited
for short-lived / short-running snippets and we don't need
clang and wasm-ld then to generate these snippets.
The JavaScript exposed debug proxy (as described in [1]) not
only enables more powerful and flexible Debug-Evaluate for the
DWARF C/C++ extension, but also serves as the basis for various
aspects of the Basic Wasm Developer Experience.
In order to pay down technical debt and to keep the maintenance
overhead low, we should remove the initial prototype now, also
to ensure that we don't accidentally attract other users of CDP
to rely on this unsupported API (despite it being marked as
"experimental").
[1]: https://docs.google.com/document/d/1VZOJrU2VsqOZe3IUzbwQWQQSZwgGySsm5119Ust1gUA
Fixed: chromium:1162062
Bug: chromium:1020120, chromium:1068571, chromium:1127914
Change-Id: I6dba8c906a8675ce6c29a52e3c32bb6626a27247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605186
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71882}
This adds ExecutionContextDescription.uniqueId for a system-unique
way to identify an execution context and supports it in Runtime.evaluate.
This allows a client to avoid accidentally executing an expression
in a context different from that originally intended if a navigation
occurs while Runtime.evaluate is in flight.
Design doc: https://docs.google.com/document/d/1vGVWvKP9FTTX6kimcUJR_PAfVgDeIzXXITFpl0SyghQ
Bug: v8:11268, chromium:1101897
Change-Id: I4c6bec562ffc85312559316f639d641780144039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594538
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71869}
Previously V8 would wrap the WebAssembly.Memory backing stores into
Uint8Arrays and report that as memories, but that's confusing to the
developer, since that's not what's really being used. The way that
DevTools presents the backing stores of memories, it's still perfectly
possible to get hold of an Uint8Array if that's what the developer is
looking for.
To make it possible to easily identify the WebAssembly.Memory objects
in the DevTools front-end (in particular for the memory inspector) we
add a 'webassemblymemory' subtype to the Chrome DevTools Protocol. We
also improve the description for the memories to include the number
of active pages.
Fixed: chromium:1155566
Screenshot: https://imgur.com/8enx57u.png
Change-Id: I63dbabe0e372e9ad6dcc8e6642cdb743147a620c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2574699
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71641}
This adds support for injecting binding into contexts other than
main based on the context name (AKA isolated world name in Blink
terms). This would simplify a common use case for addBinding in
Puppeteer and other automation tools that use addBinding to expose
a back-channel for extension code running in an isolated world by
making bindings available to such code at an early stage and in a
race-free manner (currently, we can only inject a binding into
specific context after the creation of the context has been reported
to the client, which typically introduces a race with other evals
the client may be running in the context).
Change-Id: I66454954491a47a0c9aa4864f0aace4da2e67d3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440984
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70266}
The original Profiler.getRuntimeCallStats implementation retrieved
a bunch of V8 Counters instead of runtime call counters. This
functionality is now available through the new APIs:
enableCounters, disableCounters and getCounters.
The getRuntimeCallStats API now retrieves real V8 Runtime Call Stats.
Change-Id: I702f60a6c43773f5c41b6861be3f9435975c370f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380853
Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69753}
Currently, only a scriptURL is reported, which can be over-written by
sourceURL comments of the script. This means a script can basically
claim to come from anywhere. This means that DevTools doesn't know the
resource name the embedder provided if there is a sourceURL comment.
This CL adds a `embedderName` field to the scriptParsed and
scriptFailedToParse events that reports the name the embedder
associated with the script.
Bug: chromium:974543
Change-Id: I9863f878f57638174847890d9a3818952b1efc27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317310
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69078}
evaluate() bypassed CSP for unsafe-eval by default. This is a useful
option for debugging clients, but is not always what we want.
e.g. in the devtools console we want to match the page's CSP settings
to make debugging CSP issues on the page easier.
Add a toggle that keeps the current behavior by default.
Bug: chromium:1084558
Change-Id: Ia01142d5be00f8ef5f65e5eeba17549efc6f9120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250245
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68432}
The reference types wasm proposal dropped all subtyping. Subsequently,
the 'anyref' type was renamed to externref.
This changes all references of the *type* anyref to externref.
Additionally, the flag that permits this extension is renamed to
"reftypes" to mirror the proposal name.
Bug: v8:7748
Change-Id: Icf323f13b9660fd10540e65125af053fca3a03f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232941
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68270}
Wasm modules generated by emscripten today have two ways to point to
debug symbol files, the source mapping url and external debug info
custom sections. To support both, this CL extends CDP to appropriately
report the symbol type and location.
Bug: chromium:1064248
Change-Id: I9076034f6d73901d8a9c5cfd7c2988fb30bb14c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116208
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67571}
Allow the DevTools frontend to evaluate variables in a wasm frame context by
reusing the existing Debugger expression evaluation API. Where previously the
API expected JavaScript expressions, which would in general just fail, now the
expression is expected to be base64 encoded Wasm that creates a JSON string in
linear memory.
Bug: chromium:1020120 chromium:1068571
Change-Id: I4b31fdb9d3b21b4e08c4995ec2f07880923959e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087396
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67568}
This change adds a stack scope for wasm debugging.
Currently the local scope contains both local variables as well as
the expression stack. For now, this change duplicates the information
available on stacks into the stack scope, until we have added
support for the stack scope in the DevTools front-end.
Bug: chromium:1043034
Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66867}
Add a scriptLanguage enum to the new scripts events. This overhauls
crrev.com/c/2011083 that was related. Report the code section offset
as well as the script language on the Debugger.scriptParsed and
Debugger.scriptFailedToParse events.
Bug: chromium:1057569
Change-Id: I40b43f28f0b3e094720db4fc1f07db1a0c293ee0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083025
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66749}
Coverage updates are sent as deltas, and this means that it
is very important that the consumer gets /all/ updates;
otherwise, the coverage information will be wrong.
Previously, we introduces the ability into the back-end to
send triggered updates, i.e. updates that are triggered by
the back-end at interesting points in time. These updates
are delivered via an event, and any consumer must process
these events.
This CL introduces a flag to startPreciseCoverage that
controls whether the back-end is allowed to send such
triggered updates on its own initiative. The default is
`false` to maintain backwards compatibility with consumers
that don't yet handle the events.
Bug: chromium:1022031
Change-Id: Ie36a92a3b627b19ea4041f1b8da1ec66c6b9b771
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043798
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66232}
This CL implements functionality to allow an embedder to mark a
debug scope as terminate-on-resume. This results in a termination
exception when that debug scope is left and execution is resumed.
Execution of JavaScript remains possible after a debug scope is
marked as terminate-on-resume (but before execution of the paused
code resumes).
This is used by blink to correctly prevent resuming JavaScript
execution upon reload while being paused at a breakpoint.
This is important for handling reloads while paused at a breakpoint
in blink. The resume command terminates blink's nested message loop
that is used while to keep the frame responsive while the debugger
is paused. But if a reload is triggered while execution is paused
on a breakpoint, but before execution is actually resumed from the
breakpoint (that means before returning into the V8 JavaScript
frames that are paused on the stack below the C++ frames that belong
to the nested message loop), we re-enter V8 to do tear-down actions
of the old frame. In this case Runtime.terminateExecution() cannot be
used before Debugger.resume(), because the tear-down actions that
re-enter V8 would trigger the termination exception and crash the
browser (because the browser expected the tear-down to succeed).
Hence we introduce this flag on V8 that says: It is OK if someone
re-enters V8 (to execute JS), but upon resuming from the breakpoint
(i.e. returning to the paused frames that are on the stack below),
generate a termination exception.
We deliberated adding a corresponding logic on the blink side (instead
of V8) but we think this is the simplest solution.
More details in the design doc:
https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
Bug: chromium:1004038, chromium:1014415
Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66084}
