- 17 Jan, 2022 1 commit
-
-
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:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78640}
-
- 14 Jan, 2022 1 commit
-
-
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:
Leszek 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}
-
- 13 Jan, 2022 2 commits
-
-
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:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#78610}
-
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:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78599}
-
- 03 Dec, 2021 1 commit
-
-
Kim-Anh Tran authored
This CL forwards the information that we are breaking because of a ScheduleBreak runtime call. Bug: chromium:1229541, chromium:1133307 Change-Id: I5eb9462c9df135bc3b3080c354e61e301d24e1ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310804Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#78223}
-
- 02 Dec, 2021 1 commit
-
-
Kim-Anh Tran authored
This CL makes sure to forward the information that we are pausing because of a debugger statement, and to encode it explicitly as an 'other' reason when reporting the pause to the front-end. Drive-by: refactoring the way break reasons are propagated by introducing a new enum for break reasons Bug: chromium:1229541, chromium:1133307 Change-Id: I9d2e8d8da54d96a231eff9d1f62b74507955b18f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306978Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#78202}
-
- 17 Sep, 2021 1 commit
-
-
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:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#76893}
-
- 28 Jul, 2021 1 commit
-
-
Yang Guo authored
Previously we do not tier down from baseline to interpreter, which breaks per-bytecode side effect checks (to check whether e.g. we are mutating a temporary object, which is not considered a side effect). R=leszeks@chromium.org Bug: chromium:1233401 Change-Id: Ie08b5352aa4c124421b4c9abce18326938bbc822 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056981Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#75963}
-
- 23 Jul, 2021 2 commits
-
-
Danil Somsikov authored
devtools Bug: chromium:1213374 Change-Id: Ie064873e8a3998aad01120022e39e93dba0cb729 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041424 Commit-Queue: Danil Somsikov <dsv@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#75874}
-
Dan Elphick authored
Replaces includes of v8.h with more fine-grained includes and moves the deoptimizer.h include to the places that actually need it. Bug: v8:11879 Change-Id: Ifc2e89caf455ddcf559fdb449d0fed7ad0d046d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045706Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75873}
-
- 18 Jun, 2021 1 commit
-
-
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
- 01 Jun, 2021 1 commit
-
-
Benedikt Meurer authored
In the Chrome DevTools Protocol, the step actions are named StepOut, StepOver, and StepInto, but internally we used StepOut, StepNext, and StepIn instead. This change adjusts the naming to be consistent. Bug: chromium:901814, chromium:1162229 Change-Id: Id3502a1b0a4aadd94734ec3d1fef73c1782fa220 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928510Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74877}
-
- 20 May, 2021 1 commit
-
-
Andreas Haas authored
With this CL, V8 adds an internal field to the WebAssembly Table object that is sent to DevTools to also show table entries. As WebAssembly Tables get initialized lazily, V8 only shows the name of the function instead of the function object itself. Screenshot before change: https://imgur.com/a/XFvy3lA Screenshot after change: https://imgur.com/kT84kst R=kimanh@chromium.org Change-Id: I56a0b07785ff3484f1447419fe39ae5ec3f93247 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897097Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#74690}
-
- 29 Apr, 2021 1 commit
-
-
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:
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}
-
- 28 Apr, 2021 2 commits
-
-
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:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#74249}
-
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:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74241}
-
- 12 Apr, 2021 1 commit
-
-
Benedikt Meurer authored
This is a reland of 2b94e567 Original change's description: > [inspector] Report [[Prototype]] as internal property. > > Previously the inspector was trying to add a special `__proto__` > property to every JSObject, which looked and behaved like a real > data property on the object. But this is confusing to developers > since `__proto__` is not a real data property, but usually an > accessor property on the `Object.prototype`. > > Additionally all other internal properties are reported using the > [[Name]] notation, with the [[Prototype]] having been the strange > outlier. > > Drive-by-cleanup: Use an ArrayList to collect the name/value pairs > inside Runtime::GetInternalProperties(), which makes this function > more readable and easier to add things. > > Bug: chromuium:1162229 > Fixed: chromium:1197019 > Screenshot: https://imgur.com/a/b7TZ32s.png > Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794 > Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565 > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73881} Bug: chromuium:1162229, chromium:1197019 Screenshot: https://imgur.com/a/b7TZ32s.png Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM Change-Id: Ie1e2276b385b18a5f865fdae583d1ce0101157c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2820970 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#73899}
-
- 09 Apr, 2021 2 commits
-
-
Michael Achenbach authored
This reverts commit 2b94e567. Reason for revert: Speculative based on layout test failures on win and mac which could block the roll: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Win/5294 https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Mac/4955 Original change's description: > [inspector] Report [[Prototype]] as internal property. > > Previously the inspector was trying to add a special `__proto__` > property to every JSObject, which looked and behaved like a real > data property on the object. But this is confusing to developers > since `__proto__` is not a real data property, but usually an > accessor property on the `Object.prototype`. > > Additionally all other internal properties are reported using the > [[Name]] notation, with the [[Prototype]] having been the strange > outlier. > > Drive-by-cleanup: Use an ArrayList to collect the name/value pairs > inside Runtime::GetInternalProperties(), which makes this function > more readable and easier to add things. > > Bug: chromuium:1162229 > Fixed: chromium:1197019 > Screenshot: https://imgur.com/a/b7TZ32s.png > Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794 > Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565 > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73881} Bug: chromuium:1162229 Change-Id: Ia893ad672eb370fa6fce7eddf2947bf8f6755831 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2818386 Auto-Submit: Michael Achenbach <machenbach@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@{#73886}
-
Benedikt Meurer authored
Previously the inspector was trying to add a special `__proto__` property to every JSObject, which looked and behaved like a real data property on the object. But this is confusing to developers since `__proto__` is not a real data property, but usually an accessor property on the `Object.prototype`. Additionally all other internal properties are reported using the [[Name]] notation, with the [[Prototype]] having been the strange outlier. Drive-by-cleanup: Use an ArrayList to collect the name/value pairs inside Runtime::GetInternalProperties(), which makes this function more readable and easier to add things. Bug: chromuium:1162229 Fixed: chromium:1197019 Screenshot: https://imgur.com/a/b7TZ32s.png Change-Id: Ic4c1e35e2e65f90619fcc12bf3a72806cadb0794 Doc: http://doc/1Xetnc9s6r0yy4LnPbqeCwsnsOtBlvJsV4OCdXMZ1wCM Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814565 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#73881}
-
- 17 Mar, 2021 1 commit
-
-
Igor Sheludko authored
This is a speed-for-memory tradeoff, which can be achieved by re-mapping the builtins code blob into existing code range. The feature can be enabled by v8_enable_short_builtin_calls flag and it's off by default. This CL adds GN flag and updates code generator to emit shorter pc-relative calls/jumps to builtins. However, the runtime doesn't support appearance of the off-heap builtins' PCs that point to the embedded code blob on the stack yet. Bug: v8:11527, v8:11421 Change-Id: Iaba384c549675852beae70739175976ee193ffef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727502Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#73458}
-
- 16 Mar, 2021 1 commit
-
-
Clemens Backes authored
This removes the TYPE_WASM script type, and all fields on Script that are only needed for WebAssembly. R=jgruber@chromium.org Bug: v8:11238 Change-Id: I233bfd3dec9b389bc74d926670310fd175c0c6d8 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2757690Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73418}
-
- 11 Mar, 2021 3 commits
-
-
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:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
-
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}
-
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:
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}
-
- 02 Mar, 2021 1 commit
-
-
Clemens Backes authored
This removes all wasm includes from src/debug and src/inspector if webassembly is disabled (v8_enable_webassembly=false). It also removes the definition of {WasmValueObject} and {v8::debug::WasmScript}. This will allow to later fully exclude the src/wasm directory from compilation (once other components are fixed). R=bmeurer@chromium.org, machenbach@chromium.org Bug: v8:11238 Change-Id: I41a1d83d01fbb6c015cdfd6cc063bad90052505d Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726506Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73138}
-
- 24 Feb, 2021 1 commit
-
-
Georg Neis authored
It had essentially become a synonym for BytecodeArrayAccessor. This removes the BytecodeArrayIterator class and renames BytecodeArrayAccessor to BytecodeArrayIterator. Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73005}
-
- 09 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
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/+/2643384Reviewed-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}
-
- 28 Jan, 2021 1 commit
-
-
Benedikt Meurer authored
This adds a [[WebAssemblyMemory]] internal property to ArrayBuffer and SharedArrayBuffer instances that are owned by WebAssembly.Memory objects. This allows the devtools-frontend to find the WebAssembly.Memory for any given ArrayBuffer, making it possible to properly support WebAssembly.memory.grow() eventually, but also showing a reasonable tab title. Before: https://imgur.com/hod9jPR.png After: https://imgur.com/v195VoC.png Bug: chromium:1171621, chromium:1171619, chromium:1166577 Change-Id: Ife22cabdfcf54ab30c234ea4ca86bfbb711ab2f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653155 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72403}
-
- 12 Jan, 2021 1 commit
-
-
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:
Philip 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}
-
- 11 Jan, 2021 1 commit
-
-
Eric Leese authored
New internal properties expose the byte length of an ArrayBuffer as well as the pointer to the backing store, which will serve as a unique ID to show when SharedArrayBuffers in different workers are the same buffer. Bug: chromium:1163800 Change-Id: I49930765cb38f75ba5c6cee5a0a6827f4fec42d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618242 Commit-Queue: Eric Leese <leese@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72000}
-
- 05 Jan, 2021 1 commit
-
-
Clemens Backes authored
According to the Torque definition, the type of the 'source' field is 'String|Undefined'. The Factory only allowed to pass a string though, which forced us to set an empty string for wasm scripts. This CL changes the factory to also allow undefined values, which fits slightly better for wasm. The inspector needed a minor change to handle undefined source like an empty string. R=dinfuehr@chromium.org, yangguo@chromium.org Bug: chromium:1125986 Change-Id: Iac0a5ee3767ce121aba8a6a2afe37195e77122fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584243Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71913}
-
- 29 Dec, 2020 3 commits
-
-
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:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#71893}
-
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:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#71892}
-
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:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#71891}
-
- 17 Dec, 2020 1 commit
-
-
Nico Hartmann authored
This CL changes SharedFunctionInfo::GetBytecodeArray to a function template, which is specialized for Isolate and LocalIsolate arguments. This allows main thread only uses to avoid taking a lock. Bug: v8:7790, chromium:1154603 Change-Id: I3462c4e36b66073e09393c01c765dd8a018a98f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595307 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71833}
-
- 27 Oct, 2020 1 commit
-
-
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:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70793}
-
- 24 Jul, 2020 1 commit
-
-
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:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#69034}
-
- 22 Jul, 2020 1 commit
-
-
Toan Pham authored
Some platforms disable reading of bytes in the .text section, so move the metadata into a separate .rodata section. Bug: v8:10707 Change-Id: I30ef7a180f489f175c31f9d4dcd02115c9f516c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2301113 Commit-Queue: Toan Pham <toanpham@google.com> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#68984}
-
- 02 Jun, 2020 1 commit
-
-
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:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68096}
-
- 15 May, 2020 1 commit
-
-
Marja Hölttä authored
They're exposed via DevTools. - [[PromiseStatus]] → [[PromiseState]] - [[PromiseValue]] → [[PromiseResult]] - [[GeneratorStatus]] → [[GeneratorState]] Related CLs: - Chromium CL temporarily disabling affected tests: https://chromium-review.googlesource.com/c/chromium/src/+/2203201 - Chromium CL re-enabling affected tests: https://chromium-review.googlesource.com/c/chromium/src/+/2202900 Bug: v8:10506, v8:5416 Change-Id: Id12fb0f2ba2b453139a5d74afff9021108c15f08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202984Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#67825}
-