- 26 Mar, 2020 9 commits
-
-
Nate Chapin authored
Bug: chromium:1060935 Change-Id: Ie2d92edbc9b83bf54f9009d610c13274aea32b93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119221Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/master@{#66875}
-
Andreas Haas authored
This CL fixes a spec violation that new spec tests uncovered. R=thibaudm@chromium.org CC=ecmziegler@chromium.org Change-Id: I1004eca9e4f98a0960795907fea0ab263c907938 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122022Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66874}
-
Andreas Haas authored
R=thibaudm@chromium.org Change-Id: Idb20e87e6a27a816ac1898b9e4345e5aaafaf334 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122018Reviewed-by:
-
Leszek Swirski authored
Make sure to call MaybeProcessSourceRanges in ParseOnBackground so that code coverage ranges match between main thread and background compiles. Bug: chromium:1011762 Change-Id: Ic6194083e425f4160e34a34bceb6034624cf1b9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120540Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66872}
-
Thibaud Michaud authored
The top wasm frame position can be inaccurate after removing a breakpoint and OSRing the new code. This is because we are missing the source position which was associated with that breakpoint in the old code. Fix this by explicitly introducing the missing source position. R=clemensb@chromium.org Change-Id: I0d18061c4c2411de8d2ccaaebbb4eb550a4c3160 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120591 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66871}
-
Dan Elphick authored
Now that the trace json file has changed name, update the extension checked by the --retain=json flag in generate-runtime-callstats.py. Bug: v8:10348 Change-Id: Ieb14b77d2d399a1246049170f289b4666658f376 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122015 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66870}
-
Clemens Backes authored
We were sometimes stopping on a one-shot breakpoints in JS code even though the last user action was actually a resume. This CL fixes that clearing all stepping in JS whenever we hit a breakpoint in wasm. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: Ie5d12bb0c9e766bcbd5ad0aa225a8b14b4d608b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120588Reviewed-by:
-
Dan Elphick authored
Fix generate-run-benchmark to pick the trace json file now that run_benchmark generates a different directory structure due to the protobuf change. Bug: v8:10348 No-Try: true Change-Id: I4d671071db68a7a82ec542bf41bf1d9afcdb3837 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120590Reviewed-by:
-
Kim-Anh Tran authored
This change adds a stack scope for wasm debugging. Currently the local scope contains both local variables as well as the expression stack. For now, this change duplicates the information available on stacks into the stack scope, until we have added support for the stack scope in the DevTools front-end. Bug: chromium:1043034 Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510 Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
-
- 25 Mar, 2020 16 commits
-
-
Michael Lippautz authored
std::atomic loads are marked as nodiscard on MSVC. Fix the warning by feeding the load into the USE() macro. Bug: chromium:1056170 Change-Id: I72ca42d42d268c4b961d96618250229a53709472 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120543Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#66866}
-
Ng Zhi An authored
For a bunch of s8x16, s16x2 and s32x4 shuffle ops (generated by s8x16shuffle). Bug: v8:9561 Change-Id: I0e5cd8a90edba8bc15918c0ca1dc830475db2769 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110952Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66865}
-
Leszek Swirski authored
Previously OffThreadIsolates set their thread-id on construction. This thread-id could later be used in DCHECKs, comparing it against the current thread's id. However, OffThreadIsolates are created on the main thread (as they need access to the Isolate and especially Heap for initialization). So, the thread-id was actually not the background thread's id. Now, OffThreadIsolate has a PinToCurrentThread method which should be called on whichever thread wants to actually use it. This pinning can only be done once, and the OffThreadIsolate is considered invalid before this method is called. Bug: chromium:1011762 Change-Id: Ie9d7838152683aea2a326a4e5d1dbd59a747131f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110016 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Clemens Backes authored
Using the "logSourceLocation" function from protocol-test.js prints slightly better location information for wasm, and especially much better information for JS breakpoints. This helps understanding and debugging these tests. R=thibaudm@chromium.org Bug: v8:10351 Change-Id: I51c7d168d2cb19fb8469b4a2eb372c2b95650fcb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120539Reviewed-by:
-
Seth Brenith authored
This reverts commit 0c72c719. Reason for revert: Wasm code size increase because not all pipelines use CommonOperatorReducer Original change's description: > Move branch inversion on ==0 into platform-agnostic reducer > > This change is based on a discussion from > https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696 > wherein Tobias suggested moving the folding away of ==0 operations out > of the platform-specific instruction selectors and into the > MachineOperatorReducer. I noticed that CommonOperatorReducer already > handles some very similar cases, so I have tried putting the ==0 folding > into CommonOperatorReducer instead. I'm happy to move it into > MachineOperatorReducer if that's better; I still don't have a very good > understanding of how roles are separated among reducers. > > Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66688} # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1061767 Change-Id: Id1fdfb38357eb514d92ed3be0a683f077202faa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117789 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66862}
-
Michael Lippautz authored
This adds HeapObjectHeader, a meta object that is put in front of every managed object. HeapObjectHeader provides accessors for: 1. GCInfoIndex 2. In construction bit 3. size 4. Mark bit Meta info is distributed among two uint16_t fields as (1.,2.) and (3.,4.). This is convenient as the non-bit accessors (size, GCInfoIndex) are constant during marking. Object layout see heap-object-header.h. Note: The current implementation does not bypass ASAN poisoning and assumes an unpoisoned header whenever performing an access. Bug: chromium:1056170 Change-Id: I753f15467ed5c2b22b47e64d3aa5a3c1baddf8e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116031 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#66861}
-
Leszek Swirski authored
In off-thread compilation, the ParseInfo is released on the background thread. We have to make sure to that the OffThreadParseInfoScope doesn't try to reset its per-thread data in this case. Bug: chromium:1011762 Change-Id: I6ddad6508cacc18f29e020e373783da64d3e4cb7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115431Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66860}
-
Clemens Backes authored
This enables the --debug-in-liftoff flag in the wasm-scope-info test. The expected output slightly differs, because we get another breakpoint at the end of the function body, which was actually missing before. R=thibaudm@chromium.org Bug: v8:10351 Change-Id: Ic2628b26591763cea17403f74fe0f6d935633e6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120535Reviewed-by:
-
Johannes Henkel authored
A StringView is pretty light, so this should be similar to how absl::string_view is typically used, e.g. see the guidance here: https://github.com/abseil/abseil-cpp/blob/master/absl/strings/string_view.h I suspect this reasoning holds even though StringView (defined just above StringBuffer in v8-inspector.h) carries an additional bool. This yields a small simplification of the StringBuffer implementations. Change-Id: I03f850049afe2327913070838f39649fcdfa6fa8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045110 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10347 Bug: chromium:1043034 Change-Id: I804ea511e3ed7c866e0202c97a22dcac007243e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117325 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Richard Townsend authored
MSVC 19.25 complains about signbit being ambiguous between signbit(float) and signbit(double) overloads when called with an int8_t. To remove the ambiguity, cast to a double. Change-Id: I698f05eed9248eef493bbe46b75fcd07e37e2a05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118510Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Richard Townsend <richard.townsend@arm.com> Cr-Commit-Position: refs/heads/master@{#66856}
-
Thibaud Michaud authored
R=clemensb@chromium.org Bug: v8:10321 Change-Id: I318d46fa638c1d6f4d5d347e5aa0ad1faf02d5e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120532 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Georg Neis authored
For some input types containing -0 but not +0, the result type of NumberMin and NumberMax would unnecessarily include +0. However, for some larger inputs, the result type would not include the spurious +0, thus breaking monotonicity. The CL fixes this and addresses a TODO as well. Bug: chromium:1063661 Change-Id: Icd56d6102fbea12a2d96aa063a803b1052c714b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116199 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Add LocalHandleScope to allow for local handles in LocalHeaps (background threads). This class is similar to HandleScope which still needs to be used on the main thread. When performing a GC, the main thread halts all background threads at a safepoint such that it can safely iterate their roots. Bug: v8:10315 Change-Id: Id8f5d54cc2535e004081ccdef15dc03a39b2d0f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111218 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Clemens Backes authored
A StepOver at a return (either explicit return instruction, or implicit return at the end of the function) should stop again in the caller frame. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: I313e6b612ac52e73b33ef07c6da1ced2aa0db600 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110250Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/26e9d48..de373bb Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/032c783..054d61d Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/2b2aec6..e3a49aa Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/105a846..a560ab4 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I04a2522f65cecb00308bdc0a8f7ed780fe4f3961 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119950Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66851}
-
- 24 Mar, 2020 14 commits
-
-
Clemens Backes authored
This fixes issues with replacing the return address of deeper (non-top) wasm frames, i.e. frames which are at a call position. The replaced address should also point after the call in the new code, so we don't execute the same call again. This is achieved by using slightly different encodings for breakpoint positions and other (wasm instruction) positions. Breakpoints set {is_instruction} to {false} in the source position table entry, whereas usual wasm instruction set it to {true}. Also, during stack walking for OSR, we remember whether we want to OSR to the position before the instruction (if it's the top frame), or after the call instruction (if it's deeper in the stack). We then use the {is_instruction} predicate to find the right location. R=thibaudm@chromium.org Bug: v8:10321 Change-Id: I73212a7532c6ecf4c82bde76fe4059c8203e422c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116206Reviewed-by: -
Michael Lippautz authored
As discussed offline, adding myself to OWNERS for the C++ GC, handles, and Blink embedding issues in general. Bug: chromium:1056170 Change-Id: Iff6a9f119000c04b40fb12b70f56d9bab7e32b43 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116204Reviewed-by:
-
Ng Zhi An authored
Rework the testMemoryGrowReadWrite and testMemoryGrowZeroInitialSize tests. Combine the different sized tests (32, 16, 8 bit integers) into a single base tests, taking in function arguments to specify which load/store function to call from the module exports. Also reduced the number of checks made in each test. Previously the test was asserting on every single valid offset. Now it checks the first 5 and the last 5 of each page of memory. From a quick local test using `time`, it speeds up this test on x64 from ~40s to ~20s. There is more work to be done: there are other tests below that also assert on each offset, we can change those in a future patch. The goal is to be able to run this on arm simulators sufficiently quickly, and not require to mark this test as slow. Bug: v8:7783 Change-Id: I2b17cf1811de6c26332d7e8f91efbbac3e89f6e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116601Reviewed-by:
-
Michael Lippautz authored
GCInfo and its related infrastructure is used to record information about types. Currently, we store finalization and vtable information. Future changes will introduce naming and tracing, similar to Oilpan in Blink. Information is stored in a process-wide global table that is maintained at runtime. For static builds such information can be recorded in the binary without the runtime overhead which is future work. This ports `third_party/blink/renderer/platform/heap/gc_info.{h,cc}` on a semantic level. In addition to adjusting to V8's needs, we also re-commit the already filled parts of the info table as read-only when possible, making it harder to override type information. Bug: chromium:1056170 Change-Id: Ib01eb24e6f8a94a4a647efde7af37689f8c20ba2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111214 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: -
Georg Neis authored
This DCHECK can fail because we currently pass arbitrary types in the typer unittests. Changing the tests is complicated by the fact that the compiler makes heavy use of type Any and we don't want to lose test coverage for that. Hence for now I just remove the DCHECK. I'm working on a follow-up CL but that one will not be able to land any time soon due to the current restrictions. Bug: v8:10338 Change-Id: Ibb3bb44e41b76cd91b190af184f6345cdf97d49d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116203 Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
Michael Lippautz authored
Bug: chromium:1056170 Change-Id: Id7859be3e28331a78dd548b445272cc645ce50d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116202Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port e5b4cb45 R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2198b423aa22b41b1b55f4ba733d2c2c5c3fe1ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117781 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66844}
-
Zhao Jiazhong authored
Architecture judgement functions like ‘IsMipsArchVariant’, ‘IsFpxxMode’ used to be macro functions, which may cause ‘unreachable-code’ error if they are used as condition expressions for ‘if’ statements. This CL change them to constexpr functions to avoid it. Change-Id: Id3d8473920711a05abc39265c88e91cc1cb7d5e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115833 Commit-Queue: Clemens Backes <clemensb@chromium.org> Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Clemens Backes authored
We have similar logic in place when allocating wasm memory fails. For growing, we also need to hard-abort the program, because it would cause observable differences in program behaviour otherwise. R=ahaas@chromium.org, machenbach@chromium.org Bug: chromium:1063951 Change-Id: I98f3b5364100900fce0e6553a347155a39923ca6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116036Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66842}
-
Hannes Payer authored
Bug: chromium:1056872 Change-Id: I68341f0320663796cd8487b66bb38d87c7ad8bd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115435Reviewed-by:
-
Zhao Jiazhong authored
Port e5b4cb45 https://crrev.com/c/2108299 Change-Id: Iac7e70aaa13cd46be4aaec1bf52388071ce17ae9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115835 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:10281 Change-Id: Id6c004c60e3bf142c603d9e37f730348f89cd89d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111221Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/bf3f9ee..26e9d48 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/4164a30..7977eb1 Rolling v8/buildtools/linux64: git_revision:9499562d94bf142f43d03622492e67b217461f67..git_revision:5ed3c9cc67b090d5e311e4bd2aba072173e82db9 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/bf306f5..032c783 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/befc299..2b2aec6 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I1a1926717ab4fa2f358220270ff8623695baed67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117391Reviewed-by:
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: Ia830b2fc00751abfb4dadb61651a252f1da48a1f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108299 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66837}
-
- 23 Mar, 2020 1 commit
-
-
Camillo Bruni authored
This might help reduce flaky test results caused by too high memory consumption due to the large Float32Array in regress-crbug-1057653.js. Bug: v8:10333 Change-Id: Id99ebb67ebe5a7a730e44cd8967ebbea905ccdc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108547Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#66836}
-
