- 20 Aug, 2020 1 commit
-
-
Jakob Gruber authored
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}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
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}
-
- 21 Jul, 2020 1 commit
-
-
Jakob Gruber authored
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}
-
- 24 Jun, 2020 1 commit
-
-
Camillo Bruni authored
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/+/2238569Reviewed-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}
-
- 23 Jun, 2020 1 commit
-
-
Andreas Haas authored
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}
-
- 22 Jun, 2020 1 commit
-
-
Dan Elphick authored
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/+/2257228Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68464}
-
- 17 Jun, 2020 1 commit
-
-
Jakob Gruber authored
... 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}
-
- 15 Jun, 2020 1 commit
-
-
Yang Guo authored
R=szuend@chromium.org Fixes: chromium:718827 Change-Id: I261ce2cf692b5bcf88f4f7f67249ec49c837de4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241521Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#68337}
-
- 09 Jun, 2020 1 commit
-
-
Manos Koukoutos authored
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}
-
- 03 Jun, 2020 1 commit
-
-
Andreas Haas authored
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}
-
- 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}
-
- 28 May, 2020 1 commit
-
-
Clemens Backes authored
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/+/2214838Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68045}
-
- 20 May, 2020 1 commit
-
-
Gus Caplan authored
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/+/2207805Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Gus Caplan <me@gus.host> Cr-Commit-Position: refs/heads/master@{#67927}
-
- 19 May, 2020 5 commits
-
-
Milad Farazmand authored
Port 18ac08d0 Original Commit Message: This is a reland of 3cc981cb 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}
-
Clemens Backes authored
This is a reland of 3cc981cb 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/+/2207187Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67896}
-
Clemens Backes authored
This reverts commit 3cc981cb. 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/+/2207186Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67885}
-
Clemens Backes authored
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/+/2207133Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67882}
-
Shu-yu Guo authored
I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/raep1X9R_SE/m/V8ofHrBdAgAJ Bug: v8:9801 Change-Id: I55e71b37f23ec91a01771f5584d11bc4e5939da4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207920 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67881}
-
- 18 May, 2020 1 commit
-
-
Clemens Backes authored
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/+/2206736Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67865}
-
- 12 May, 2020 1 commit
-
-
Clemens Backes authored
This is a reland of 902f48bd, 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}
-
- 11 May, 2020 2 commits
-
-
Shu-yu Guo authored
This reverts commit 902f48bd. 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/+/2194372Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67720}
-
Clemens Backes authored
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}
-
- 06 May, 2020 1 commit
-
-
Jakob Gruber authored
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/+/2182429Reviewed-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}
-
- 01 May, 2020 1 commit
-
-
Seth Brenith authored
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}
-
- 30 Apr, 2020 1 commit
-
-
Marja Hölttä authored
CL adopted from joshualitt@: https://chromium-review.googlesource.com/c/v8/v8/+/2002932 Link to explainer is here: https://github.com/tc39/proposal-promise-anyCo-authored-by: Joshua Litt <joshualitt@chromium.org> Bug: v8:9808 Change-Id: I6872020e857d4b131d5663f95fd58e6271ccb067 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124834 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67502}
-
- 16 Apr, 2020 3 commits
-
-
Clemens Backes authored
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}
-
Clemens Backes authored
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/+/2151356Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67176}
-
Georg Neis authored
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}
-
- 15 Apr, 2020 1 commit
-
-
Clemens Backes authored
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/+/2144070Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67145}
-
- 14 Apr, 2020 1 commit
-
-
Clemens Backes authored
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}
-
- 08 Apr, 2020 5 commits
-
-
Clemens Backes authored
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}
-
Clemens Backes authored
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/+/2142256Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67064}
-
Clemens Backes authored
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/+/2140938Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67057}
-
Clemens Backes authored
Debugging with multiple isolates involved is known to be broken. Thus skip another test which flakes currently. TBR=thibaudm@chromium.org Bug: v8:10359 Change-Id: Ib0758794623cca1cf9bdd6d6d8aa673ceffd9d7c No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140933Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67052}
-
Clemens Backes authored
This is a reland of 44826509. TSan issue were fixed in https://crrev.com/c/2139574. One test failing in the 'stress' variant is skipped for now, until we figure out what the intended behaviour actually is. Original change's description: > [wasm] Debug in Liftoff by default > > This flips the --debug-in-liftoff flag to be on by default. > There are still some outstanding issues with that configuration, but not > more than with the interpreter configuration. Thus flip now, such that > we can fully focus on stabilizing that config. > > R=ecmziegler@chromium.org > > Bug: v8:10351 > Change-Id: I7681f40aa2516557ef3ab4efd9a2c1f88e3b4df7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135727 > Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67018} Bug: v8:10351, v8:10403 Change-Id: I4c2f1af46233546d6ebeb638c7ef10aac56cd92d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139575 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#67049}
-
- 06 Apr, 2020 1 commit
-
-
Dan Elphick authored
Change-Id: I2097c5dec4d909a7e259a081706ad79a8a1684bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137414 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67021}
-
- 30 Mar, 2020 1 commit
-
-
Clemens Backes authored
Debugging does not work reliably with multiple isolates involved. Thus skip all tests that we saw flaking so far. R=thibaudm@chromium.org Bug: v8:10359, v8:10358 Change-Id: I119f8fdb19efb91f7d9fad0f510ffb68c646e784 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126906Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66906}
-
- 09 Mar, 2020 1 commit
-
-
Z Nguyen-Huu authored
Bug: v8:10290 Change-Id: I35670fef49a89cd075fb654daec4b55440266673 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2088231 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66634}
-
- 18 Feb, 2020 1 commit
-
-
Z Nguyen-Huu authored
Store a flag per isolate whether new modules should be kept in tiered-down state from the beginning. Adjust initial compilation if flag is set. Bug: v8:9654 Change-Id: I5aae435fb807f3eaa7efafe9af60451ad3c7e14d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028452 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66321}
-
- 09 Feb, 2020 1 commit
-
-
Z Nguyen-Huu authored
If both isolates run this test, they are kind of racing on the {tier_down_} flag, hence you get unexpected results. Bug: v8:10189, v8:10099 Change-Id: I8657c32c024898442d5c916cf15077c846276b1f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044544 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66188}
-