This reverts commit 2b94e5677f.
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/5294https://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}
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}
This changes the behavior of SetBreakpointForScript to find more
accurate break positions.
Previously, setting a breakpoint would only consider the shared
function info that contained the requested position for setting a
breakpoint. More intuitively, a breakpoint should not necessarily
be set in a function that contains the position, but in the closest
breakable location that comes after the position we requested.
To achieve this we:
1. find the shared function info of the inner most function
that contains the requested_position.
This function's end position is used to find other shared function
infos in step 2.
2. search for all shared function infos that intersect with the
range [requested_position, inner_most_function.break_position[.
3. From the shared function infos extracted in 2, find the one
that has the closest breakable location to requested_position.
Also-By: bmeurer@chromium.org
Fixed: chromium:1137141
Change-Id: I4f4c6c3aac1ebea50cbcad9543b539ab1ded2b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742198
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73392}
This CL introduces a test runner flag to detect if webassembly has been
disabled. Since all tests that require wasm are alrady skipped in
lite mode, we introduce a has_webassembly flag for the test runner which
checks for v8_enable_webassembly=true and v8_enable_lite_mode=false.
As a drive-by, we also do not set the V8_ENABLE_WEBASSEMBLY
preprocessor flag if lite mode is enabled.
The status files are updated by splitting wasm tests from the
"lite_mode" section and checking for "not has_webassembly" instead.
Note that the v8_enable_webassembly=false configuration is not tested
on any bot currently, but I will make sure that all tests keep passing
on further changes in this configuration.
R=machenbach@chromium.org
Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I1841eb1f1633cb47e0c079f4a4a4d769ca3a9cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72898}
This reverts commit b471bc9318.
Reason for revert: Seems like we don't reliably deliver scriptParsed events on reload after this CL.
Original change's description:
> [wasm] Send a single scriptParsed event per script
>
> If a script was shared between multiple modules (because they used the
> same wire bytes) it could happen that we still triggered multiple
> "scriptParsed" events via CDP. This was because
> {WasmEngine::GetOrCreateScript} did not communicate back whether it
> used a cached script or whether it created a new one.
>
> This CL moves the call to {Debug::OnAfterCompile} (which triggers the
> "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
> such that we only call it once per script.
> Since the engine only holds a weak reference to the script, we would
> still trigger multiple events if the script is garbage-collected in the
> meantime. In this case there is no way around this, as the new script
> would have a new ID, hence we need to emit a new event to make it
> public to the debugger.
>
> R=thibaudm@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1151211
> Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
> Reviewed-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@{#72648}
TBR=clemensb@chromium.org,bmeurer@chromium.org,thibaudm@chromium.org
Change-Id: I6cc299734e4fcff29289355973e7660b60b49a25
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1151211
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689199
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72667}
If a script was shared between multiple modules (because they used the
same wire bytes) it could happen that we still triggered multiple
"scriptParsed" events via CDP. This was because
{WasmEngine::GetOrCreateScript} did not communicate back whether it
used a cached script or whether it created a new one.
This CL moves the call to {Debug::OnAfterCompile} (which triggers the
"scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
such that we only call it once per script.
Since the engine only holds a weak reference to the script, we would
still trigger multiple events if the script is garbage-collected in the
meantime. In this case there is no way around this, as the new script
would have a new ID, hence we need to emit a new event to make it
public to the debugger.
R=thibaudm@chromium.orgCC=bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
Reviewed-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@{#72648}
They've started failed, and no work is planned for the foreseeable
future.
Bug: v8:8888
Change-Id: I89dfa8f972a5bffa2bbb09c7a6ca56a0c4da9a02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656316
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72407}
Liftoff is not fully feature complete yet. To test that Liftoff can
bailout to TurboFan also for debugging, this CL adds
* an opcode that is only implemented in TurboFan
* a flag that allows that opcode to be compiled with TurboFan
* a bailout for this opcode to Liftoff.
R=clemensb@chromium.org
Bug: v8:7581
Change-Id: Ie4b4654d0d36ab937a7dfe9b1bb6a187b17615fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629284
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72113}
While working on C++ debug evaluate, we found that several builtins and
intrinsics aren't marked as side effect free, although they are clearly
side effect free, and that breaks the C++ side effect free evaluation.
- %DefineClass() and %TypedArray%.of(), and
- various WebAssembly getters ("buffer", "exports" and "length") as
well as the C++ functions for the debug proxy.
Also-By: pfaffe@chromium.org
Bug: chromium:1137514
Change-Id: Iebd333dc2014f1ad218908f64c9199c157dc08b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565135
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71498}
This specific case was not implemented or tested before. Implementing it
actually simplifies some of the existing logic, since StepOut can now
reuse the generic logic in debug.cc for all cases (Wasm->Wasm, Wasm->JS,
JS->Wasm).
Drive-by:
1) Fix typo ("skip" -> "step").
2) Move the check for Liftoff code from debug.cc to wasm-debug.cc, where
it fits better.
3) Remove a TODO which is done already.
R=thibaudm@chromium.org, szuend@chromium.org
Bug: chromium:1145176
Change-Id: I415ca1d8bacef5b21bf1dafd9e16417ec2d12c7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560719
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71428}
This changes remoteObjectId format from
"{injectedScriptId:123,id:456}" to "<isolateId>.<contextId>.<id>".
Prepending isolateId fixes the problem that
remote object ids clash between processes. This is especially
troubling during cross-process navigation in Chromium, see bug.
We also stop producing and parsing unnecessary json for object ids.
Drive-by: fixed some tests dumping object ids. Most tests avoid
dumping unstable values like ids, but there were few that still did.
BUG=chromium:1137143
Change-Id: Ia019757fb95704ccb718d3ea6cc54bde1a133382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461731
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70592}
To properly test tier-up in the V8 test suite, change the test variant
previously called --turbo-nci-as-highest-tier to
--turbo-nci-as-midtier. As a midtier (between ignition and turbofan),
all major parts of the NCI pipeline (codegen, caching inside the same
native context, tier-up) are exercised by test suite.
Bug: v8:8888
Change-Id: Ic8ee2f3e3d72768c3869f5e0b25800dd0a5f25b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361462
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69501}
Just like the optimized code cache, the compiler should check the
isolate cache for NCI code objects and return them if they exist.
Drive-by: Skip additional tests to fix the nci_as_highest_tier test
variant. These are related to interactions with deoptimization, which
NCI code doesn't fully support yet.
Bug: v8:8888
Change-Id: I6253811f96993796cfc38fff0da7ffb4f1a5eb24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339095
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69251}
With work on NCI proceeding, it makes sense to test multiple
pipeline configurations.
The nci variant (passes --turbo-nci) now spawns dedicated NCI
compilation jobs and inserts generated code into the code cache.
The nci_as_highest_tier variant (passes --turbo-nci-as-highest-tier)
simply replaces TF with NCI code (no extra jobs, no extra caching).
This mode stresses NCI generated code more than the nci variant, in
which NCI code only runs on cache hits.
Bug: v8:8888
Change-Id: I4c2a43cce5271a6c288e7aba195dcc9daed6af9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299361
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68964}
With this CL d8 exits with an error code if there is an unhandled
promise rejection, e.g. due tue a failed assertion in a promise. Up
until now these assertions were just ignored.
Bug: v8:10556
Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68503}
Due to recent spec changes, this CL removes the type immediate of
ref.is_null again. Instead we check if the type of the input parameter
is nullable.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: If07d30fe4dd27664be7774422573b2ab2b0dfa20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247654
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68484}
This changes black/white list to block/allow list.
Bug: v8:10619
Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68464}
... for nci code, in which several phases of the compiler are not
active:
LowerJSCreateCatchContext
LowerJSCreateEmptyLiteralObject
LowerJSCreateIterResultObject
LowerJSCreateWithContext
LowerJSGetIterator
LowerJSGetTemplateObject
With this change, the nci variant passes the test suite. Tests
relying on turbofan-specific behavior (e.g. deopts) are skipped.
Bug: v8:8888
Change-Id: I709178241e9b25e7480a39b4fb64bdcf576483be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245604
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68381}
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}
With recent changes to the anyref proposal, null refs now have a type
immediate which declares the type of a null ref constant. Likewise,
the RefIsNull instruction is type aware now. This CL addresses these
proposal changes now.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I810dfa3a4ab4389afc9639f897cee5d43e9b62cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215172
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68141}
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/+/2218059
Reviewed-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}
Instead of keeping a single {stepping_frame_} per native module, we now
keep one frame id per isolate. Hence, each isolate can step through a
different frame, independent of other isolates.
The on-stack-replacement of the stepping frame already works on a
per-isolate basis, since we only replace the return address of a single
frame, part of the isolate that requested stepping.
The new test (which also executes in a variant with two concurrent
isolates) revealed some more data races to fix.
R=thibaudm@chromium.org
Bug: v8:10359
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I0bb013737162bd09b9f4be9c08990bca7bf736ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214838
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68045}
Math.random, while technically not having any effects which modify the
surrounding JS state, does observably change between a no-side-effects
evaluation and an actual evaluation, and can cause confusion.
Change-Id: I4a41ac6fd3153a14245d5940fe52ada43ca05e0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207805
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Gus Caplan <me@gus.host>
Cr-Commit-Position: refs/heads/master@{#67927}
Port 18ac08d03c
Original Commit Message:
This is a reland of 3cc981cb7a with a
fix for data race detected by TSan.
Original change's description:
> [wasm][debug] Fix tier down during streaming compilation
>
> If the debugger is enabled while streaming compilation is happening, we
> won't correctly tier down to Liftoff. This is because during streaming
> compilation, we always compile for no debugging. Fixing that is a bit
> tricky, since when the debugger is enabled, functions can either already
> have finished compiling, or they are currently being compiled, or their
> wire bytes are not received yet.
> Instead of handling this correctly while streaming compilation is
> running, we just recompile the whole module with Liftoff after streaming
> compilation finished.
>
> For testing this, we use the existing tests for async compilation, and
> enable --wasm-test-streaming, which compiles via the streaming decoder
> even in the async compilation case.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10531
> Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67882}
R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I778a10eaba0016a9e897c8f71ac822c6b421350f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208901
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67906}
This is a reland of 3cc981cb7a with a
fix for data race detected by TSan.
Original change's description:
> [wasm][debug] Fix tier down during streaming compilation
>
> If the debugger is enabled while streaming compilation is happening, we
> won't correctly tier down to Liftoff. This is because during streaming
> compilation, we always compile for no debugging. Fixing that is a bit
> tricky, since when the debugger is enabled, functions can either already
> have finished compiling, or they are currently being compiled, or their
> wire bytes are not received yet.
> Instead of handling this correctly while streaming compilation is
> running, we just recompile the whole module with Liftoff after streaming
> compilation finished.
>
> For testing this, we use the existing tests for async compilation, and
> enable --wasm-test-streaming, which compiles via the streaming decoder
> even in the async compilation case.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10531
> Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67882}
Bug: v8:10531, v8:10544
Change-Id: I884922b6ac55543e6ff9b1046438f6b3abab6f64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207187
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67896}
This reverts commit 3cc981cb7a.
Reason for revert: TSan failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/31572
Original change's description:
> [wasm][debug] Fix tier down during streaming compilation
>
> If the debugger is enabled while streaming compilation is happening, we
> won't correctly tier down to Liftoff. This is because during streaming
> compilation, we always compile for no debugging. Fixing that is a bit
> tricky, since when the debugger is enabled, functions can either already
> have finished compiling, or they are currently being compiled, or their
> wire bytes are not received yet.
> Instead of handling this correctly while streaming compilation is
> running, we just recompile the whole module with Liftoff after streaming
> compilation finished.
>
> For testing this, we use the existing tests for async compilation, and
> enable --wasm-test-streaming, which compiles via the streaming decoder
> even in the async compilation case.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10531
> Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67882}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: I26e750c6c6d0783b5e4a0f19a5462a5fbe99a742
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10531
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207186
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67885}
If the debugger is enabled while streaming compilation is happening, we
won't correctly tier down to Liftoff. This is because during streaming
compilation, we always compile for no debugging. Fixing that is a bit
tricky, since when the debugger is enabled, functions can either already
have finished compiling, or they are currently being compiled, or their
wire bytes are not received yet.
Instead of handling this correctly while streaming compilation is
running, we just recompile the whole module with Liftoff after streaming
compilation finished.
For testing this, we use the existing tests for async compilation, and
enable --wasm-test-streaming, which compiles via the streaming decoder
even in the async compilation case.
R=thibaudm@chromium.org
Bug: v8:10531
Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67882}
Asynchronicity can be tricky, in particular if the debugger is enabled
while wasm compilation is happening.
We seem to have open issues in streaming compilation there. As a first
step, which CL adds more tests for async compilation (non-streaming).
R=thibaudm@chromium.org
Bug: v8:10531
Change-Id: Idf16790a91aad437ceb981485512a2f52b791bac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2206736
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67865}
This is a reland of 902f48bdda, fixed
to avoid lock inversion problems detected by TSan.
Original change's description:
> [wasm][debug] Fix tier down for multiple isolates
>
> If multiple isolates are using the same module, we need to keep it
> tiered down as long as any isolate still has a debugger open.
> Also, we cannot short-cut the {NativeModule::TierDown} method, since the
> previously triggered tier down might not have finished yet.
> For now, each isolate starts an independent tier down (i.e. a full
> recompilation). We could optimize this later by skipping functions that
> are already tiered down, or are already scheduled for tier down, but we
> still need to wait for tier-down to finish on each isolate.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10359
> Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67716}
Bug: v8:10359
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: Ie98cf073fc79e5c6991df6d4466de7b560274070
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194451
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67754}
This reverts commit 902f48bdda.
Reason for revert: Made TSAN unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/9480
Original change's description:
> [wasm][debug] Fix tier down for multiple isolates
>
> If multiple isolates are using the same module, we need to keep it
> tiered down as long as any isolate still has a debugger open.
> Also, we cannot short-cut the {NativeModule::TierDown} method, since the
> previously triggered tier down might not have finished yet.
> For now, each isolate starts an independent tier down (i.e. a full
> recompilation). We could optimize this later by skipping functions that
> are already tiered down, or are already scheduled for tier down, but we
> still need to wait for tier-down to finish on each isolate.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10359
> Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67716}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: Ibf650e8b6143471b44f2822c1737e7de5f8bdb20
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10359
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194372
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67720}
If multiple isolates are using the same module, we need to keep it
tiered down as long as any isolate still has a debugger open.
Also, we cannot short-cut the {NativeModule::TierDown} method, since the
previously triggered tier down might not have finished yet.
For now, each isolate starts an independent tier down (i.e. a full
recompilation). We could optimize this later by skipping functions that
are already tiered down, or are already scheduled for tier down, but we
still need to wait for tier-down to finish on each isolate.
R=thibaudm@chromium.org
Bug: v8:10359
Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67716}
The serializer currently cannot handle a heap state containing
arbitrary compiled Code objects. As a quick fix for the
--stress-snapshot d8 flag, we clear compiled data from the isolate
prior to the serialize-deserialize-verify pass.
With this change, mjsunit tests pass on x64.
The %SerializeDeserializeNow() runtime function would require more
work, since it is not possible to mutate the heap to this extent while
still preserving a runnable host context and isolate. We will need
another solution there.
Drive-by: Skip the stress_snapshot variant except for the mjsunit
suite.
Tbr: machenbach@chromium.org
Bug: v8:10493,v8:10416
Change-Id: Ie110da8b51613fcd69c7f391d3cf8589d6b04dd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182429
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67585}
Any function with heap-allocated variables starts by creating and
pushing a new context for its execution. When entering the debugger due
to the stack check in the beginning of InterpreterEntryTrampoline, the
function has not yet had a chance to push that new context. The code in
ScopeIterator currently assumes that any function which needs a context
already has one by the time the debugger attempts to iterate scopes, but
in this case that assumption is invalid, which can cause a null deref.
This change introduces a new function ScopeIterator::NeedsAndHasContext
to replace previous calls to current_scope_->NeedsContext(). This new
function checks for the case where the current scope matches the closure
scope but the context matches the containing context for the function,
which implies that the function has not yet pushed its own context.
Bug: v8:10319, chromium:1038747
Change-Id: I29636f269c44d35b68d8446769d17170eed50e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168021
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67519}
These tests were skipped three years ago because of flakes. I cannot
reproduce the flakes any more, so reenabling the tests.
R=petermarshall@chromium.org
Bug: chromium:772010
Change-Id: I4dc2d890b20e642f8d9351676aecab965d2b4b63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151357
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67182}
The failure was probably the same as in https://crbug.com/v8/10410. Thus
reenable the test also in the stress_incremental_marking variant on
windows.
R=thibaudm@chromium.org
Bug: chromium:772010, v8:10410
Change-Id: Iad0b9b60408e08c5f2202462f6eeba3067525ae5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151356
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67176}
Change-Id: Ic5dbf4c3330c71cbae73aa07b2adb1c8ac087182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151348
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67172}
The underlying issue was fixed in https://crrev.com/c/2144116 and
https://crrev.com/c/2142259. This reenabled the test generally. Note
that it's still skipped in special configurations. I will reevaluate
which of those can also be unskipped via separate CLs.
Drive-by: Fix the order of "expected" and "actual" values.
R=thibaudm@chromium.org
Bug: v8:10410
Change-Id: Idbdcc73d641661e96e12110dcf10b060e0cf47a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144070
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67145}
This adds a flag to {WasmCode} objects to store whether this code was
generated for debugging. This flag can be set for Liftoff code (in which
case the code will e.g. have an extended prologue for debugging), but it
can also be set for TurboFan, in case Liftoff bailed out when producing
the debugging code.
Having this flag allows us to remove the hack to pass the compilation
results to {OnFinishedUnits} just to check whether we actually wanted to
compile Liftoff functions.
Drive-by: Replace the {ReachedRecompilationTierField} by a
{MissingRecompilationField}, because all we need to know is if we are
still waiting for that function to get recompiled.
R=ahaas@chromium.org
Bug: v8:10330,v8:10410
Change-Id: Ia023df8955a60d9f5595a6cb2737e14d83baf716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142259
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67119}
This test is already skipped in different configuration, but it still
generally flakes. We need to investigate more before re-enabling it in
all configuration that we want to support.
R=nicohartmann@chromium.org
Bug: v8:10410
Change-Id: I382e168add952d8e9f4802306a9029ea9651a389
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142263
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67067}
Several JS tests are already skipped in that config. This CL adds a wasm
test that also started flaking.
TBR=thibaudm@chromium.org
Bug: v8:10410, chromium:772010
Change-Id: Ie16d60a5066a56005d9cf1e4951d6ed1c17e4dc7
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142256
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67064}
Debugging with multiple isolates involved is known to be broken.
TBR=thibaudm@chromium.org
Bug: v8:10359
Change-Id: I2f32cd4b7b53492508948a85e9750167b25b8d89
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140938
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67057}
