- 27 Apr, 2021 4 commits
-
-
Lu Yahan authored
xori rd, rs, 0x1 mean is that negating bit 0 of rs. So we can delte xori and invert the condition of the branch. Change-Id: I318b7a2def6ec5d848757f85623564922abfcdc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2847673 Commit-Queue: Yahan Lu <yahan@iscas.ac.cn> Reviewed-by: Brice Dobry <brice.dobry@futurewei.com> Cr-Commit-Position: refs/heads/master@{#74197}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/0ee8b27..84e217e Rolling v8/third_party/aemu-linux-x64: E8miK3g03NZQFrVhyywlfhYSWXsq2SfF7vw2pdW-doYC..GCNw2-mtXN7PnLi5hLQH5ab_ViULLYtqr5C1KX36CYQC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8bc6b08..1727be6 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/61bf6e8..90aee2a Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/058fb58..86da5ec Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/d25bdc0..cd9f9a9 TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ia892f8b95d147532ed915d4908871c0d5f2f309c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2852466Reviewed-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@{#74196}
-
Lu Yahan authored
Change-Id: I7cf47d9be50790f453bd2908b58aff3a41e2f95b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848735Reviewed-by: Brice Dobry <brice.dobry@futurewei.com> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn> Cr-Commit-Position: refs/heads/master@{#74195}
-
Michael Lippautz authored
Bug: chromium:1056170 Change-Id: I0206078a672cb66edf6590430b35b7c3bc9ce1eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2852238 Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74194}
-
- 26 Apr, 2021 30 commits
-
-
Zhi An Ng authored
This reverts commit d2ce5744. Reason for revert: We reverted the early canonicalization change, so we need to worry about non-canonicalized shuffles now. Original change's description: > [wasm-simd][arm64] Update f32x4.mul(dup) pattern matching > > We now canonicalize earlier in the pipeline, and don't need to worry > about non-canonicalized shuffles. > > Bug: v8:11542,v8:11257 > Change-Id: If9f5c44061465be339c98e479fd8c5a437bbd74b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778673 > Reviewed-by: Bill Budge <bbudge@chromium.org> > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73645} Bug: v8:11542 Bug: v8:11257 Change-Id: Ib492b3ab7ad140193975d2641999c12c9697e27b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850630Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#74193}
-
Michael Lippautz authored
- Move LsanPageAllocator to base; - Use LsanPageAllocator in PageBackend that serves managed C++ objects; - Remove spurious TODO for GCInfoTable which should not use the LSAN-aware backend; Bug: chromium:1056170 Change-Id: I2caa11443ab44da5164f1c29339e302bffb49228 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850157 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74192}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/665fcc3..0ee8b27 Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxabi/+log/d0f3388..f6a8e55 Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/08f35c8..5844fc6 Rolling v8/third_party/aemu-linux-x64: RHTOD0RSgoWm-M1jtnmPhZKKrWS0SGcMPzXuBTCbIUYC..E8miK3g03NZQFrVhyywlfhYSWXsq2SfF7vw2pdW-doYC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d628425..8bc6b08 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/efd29f6..61bf6e8 Rolling v8/third_party/google_benchmark/src: https://chromium.googlesource.com/external/github.com/google/benchmark/+log/7f27afe..058fb58 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/7e7574b..d25bdc0 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/d7dd881..ba668f1 Rolling v8/tools/luci-go: git_revision:0f913477afc80d5c4b6609834d3bef6b44910e67..git_revision:173195137e006c3bbbd2394409e3d752f8b3c62f Rolling v8/tools/luci-go: git_revision:0f913477afc80d5c4b6609834d3bef6b44910e67..git_revision:173195137e006c3bbbd2394409e3d752f8b3c62f Rolling v8/tools/luci-go: git_revision:0f913477afc80d5c4b6609834d3bef6b44910e67..git_revision:173195137e006c3bbbd2394409e3d752f8b3c62f TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I5e981c75993c85188e579264cc46f1c77c200b57 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2849981 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#74191}
-
Shu-yu Guo authored
https://chromium.googlesource.com/external/github.com/tc39/test262/+log/311265..70bc32 Bug: v8:7834 Change-Id: Ie2de0088d9baeaa2635749035030a7d86eee368d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846157Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74190}
-
Maya Lekova authored
This CL ensures googletest is built with the build configuration used for other components of V8. This works around the issue that googletest is compiled with hidden visibility, even in configurations that compile with default visibility, such as when v8_enable_backtrace is provided. Bug: chromium:1191946 Change-Id: I70fa3ce0a668a71a091607c22d2dda67e496fec4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850700Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#74189}
-
Ulan Degenbaev authored
Bug: chromium:1173527 Change-Id: Ib5ec5732b442539ad112acaef3c2898f03082650 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835733Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74188}
-
Liviu Rau authored
Bug: chromium:1064551 Change-Id: I925fdce3133e4e603aea3ad67656b0f3bb0dd89c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848408Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#74187}
-
Ulan Degenbaev authored
All existing usages are changed to Factory::NewFixedArray(). The motivation for the removal is that the function is unsafe and easy to misuse. Note that NewUninitializedFixedArray has been already changed to initialize the result as an experiment with 3%-13% regression on a few SixSpeed microbenchmarks and no impact on larger benchmarks. Change-Id: I2e084bc03b2636aa6d368ca255970566a7ce222e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846895 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74186}
-
Andreas Haas authored
Bug: chromium:1197703 Change-Id: I36fd8b6ef4105e7deab9617d3cd1f2eb44e08171 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850650Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#74185}
-
Yahan Lu authored
Port: a1616e6f Change-Id: Idfb48da2e38948b23efdc129da8949200f0896c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814723 Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Reviewed-by: Brice Dobry <brice.dobry@futurewei.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74184}
-
Mike Stanton authored
During background compilation, we check SharedFunctionInfo::HasBreakInfo() to see if the function has breakpoints for debugging, generally deciding not to inline the function if so. We were concerned about the status of this bit changing on the main thread. Happily, the main thread deoptimizes all functions that inline the given function, and shuts down all background compilation jobs as well. So it is not a meaningful concern (that of say, ignored breakpoints). Updated a comment to record this finding. Bug: v8:7790 Change-Id: I7adbc5d19fc45eb7f4df1400c33f5988d9dac58d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848409 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74183}
-
Santiago Aboy Solanes authored
This is a reland of fd16e67e. https://chromium-review.googlesource.com/c/v8/v8/+/2843813 Reason for reland: The reland was reverted due to TSAN no-cm flakily failing due to races with the ProtectorCells[1]. The protector cells part of the method was removed in a refactor[2]. Therefore, we can re-reland with minor rebase changes in heap-refs.cc (heap.cc remains the same). [1]: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/3413 [2]: https://chromium-review.googlesource.com/c/v8/v8/+/2839553/7/src/compiler/heap-refs.cc Bug: v8:7790 Change-Id: I976ab10c6398cffe5c5b87b28d9be0de2dd6261c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850638Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74182}
-
Dominik Inführ authored
This will help reducing the time needed to reach a Safepoint() on the main thread. During startup main_thread_local_isolate() is not initialized when Heap::AllocateRaw() is invoked. Solve this by only running Safepoint() after deserialization is completed. Bug: v8:10315 Change-Id: I281fdbe5cebcd7946d687f56676c0d563792fde5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835714 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74181}
-
Andreas Haas authored
R=clemensb@chromium.org Bug: chromium:1196837 Change-Id: I8945e25be12155482e1feefe1cfd980a94b0488d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850646Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#74180}
-
Clemens Backes authored
This adds a test variant enabling --wasm-write-protect-code-memory, and enables it on linux64 debug and release bots. R=machenbach@chromium.org, jkummerow@chromium.org CC=dlehmann@google.com Bug: v8:11667, v8:11663 Change-Id: I04f47d06d9720f7bc9e122d17b253646f2c203b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839562 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74179}
-
Ross McIlroy authored
Instead of running a second pass of the scheduled graph after effect control linearization to do machine lowering, integrate the machine lowering reducers (MemoryLowering and SelectLowering) into the graph assembler used by the effect control linearization. This saves running through the graph and re-maintaining the schedule for the second time, reducing overhead in Turboprop. BUG=v8:9684 Change-Id: Ib0fed19089287c8e801a063333cb8404181411db Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848474 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74178}
-
Alex Rudenko authored
Bug: chromium:1169639 Change-Id: I3939b2e8568f0df12ecce192edca6df2b33e3835 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839551Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Alex Rudenko <alexrudenko@chromium.org> Cr-Commit-Position: refs/heads/master@{#74177}
-
Michael Achenbach authored
Bug: chromium:1199430 Change-Id: I4b82b0ef4323f6636a49a41fef20aded0ab38674 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848479Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74176}
-
Clemens Backes authored
We were inconsistent in handling offsets >= 2GB on 32-bit systems. The code was still relying on this being detected as statically out of bounds, but with the increase of {kV8MaxWasmMemoryPages} to support 4GB memories, this is not the case any more. This CL fixes this by again detecting such situations as statically OOB. We do not expect to be able to allocate memories of size >2GB on such systems. If this assumptions turns out to be wrong, we will erroneously trap. If that happens, we will have to explicitly disallow memories of such size on 32-bit systems. R=jkummerow@chromium.org Bug: v8:7881, chromium:1201340 Change-Id: Ic89a67d38fb860eb8a48a4ff51bc02c53f8a2c2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848467Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74175}
-
Santiago Aboy Solanes authored
The property kInObjectPropertiesStartOrConstructorFunctionIndexOffset was set as relaxed due to races with the layout_descriptor (https://chromium-review.googlesource.com/c/v8/v8/+/555210/). The layout_descriptor was removed with the removal of double field unboxing. We are able to turn those property's accessors into non-atomic ones since they are set at construction time. Bug: v8:7790 Change-Id: I25c53f0e00718cca72ba86f8475af9ecefb7ba3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843359 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74174}
-
Leszek Swirski authored
It's unfortunate that there is both a LocalIsolate template parameter, and an actual LocalIsolate class. Clean this up by renaming the template parameters to IsolateT Change-Id: Iecefc3eca5aeb7bbd21e78818b90f9e75cdff10f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846880 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74173}
-
Jakob Gruber authored
Bug: v8:7790 Change-Id: I388a833810b3620eddcecc24fd571eda146fb785 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843353Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74172}
-
Jakob Gruber authored
Prior to this CL, Refs were defined through four lists: HEAP_BROKER_SERIALIZED_OBJECT_LIST HEAP_BROKER_POSSIBLY_BACKGROUND_SERIALIZED_OBJECT_LIST HEAP_BROKER_BACKGROUND_SERIALIZED_OBJECT_LIST HEAP_BROKER_NEVER_SERIALIZED_OBJECT_LIST Due to the way FooData objects are constructed (a long if-else chain generated from these lists), the order of entries within the lists and also between lists was important. In particular, subtypes had to appear before all their supertypes. Within one list this was doable, but with the split into 4 different lists this invariant cannot hold in practice. This CL refactors the four lists back into a single list to make observing the invariant possible with upcoming changes. The new unified list contains the RefSerializationKind as a second argument. Related changes are not very interesting, except for TryGetOrCreateData which now uses a set of templated functor objects for setup (this was necessary to handle different FooData constructor signatures). Bug: v8:7790 Change-Id: Ia4c030c767830be4253cf41e3aaf67454f1cbef6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843351 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74171}
-
Patrick Thier authored
Change-Id: I1ddb64331053e969edd81debb69cc06b80c1095f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850635 Commit-Queue: Patrick Thier <pthier@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74170}
-
Mathias Bynens authored
Prior to this patch, `new RegExp('a/b')` logs the following in the DevTools Console: /a/b/ This is syntactically invalid. This patch fixes this while simplifying regular expression printing in general by leveraging `RegExp#toString`, instead of duplicating the logic on the inspector side. This is possible thanks to the recent work on making `RegExp#toString` more robust (v8:1982). Bug: chromium:1202013, v8:1982 Change-Id: I14ccc1892f4a99361ad170fea608ace630740991 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848463 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#74169}
-
Ulan Degenbaev authored
This restores the check that was removed in https://chromiumcodereview.appspot.com/12300020/ Bug: chromium:736643 Change-Id: I82e218b9f2572953a7f433d713dff0528574eea1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848469Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74168}
-
Michael Achenbach authored
No-Try: true Bug: chromium:1199430 Change-Id: I904a81a0c3e7c66addbcd5da1e44373d6cc6c350 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848478 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#74167}
-
Jakob Gruber authored
On a per-job basis, --turbo-direct-heap-access should be equal to whether concurrent inlining is enabled. We simplify involved logic by removing the flag, and replacing all access to - FLAG_turbo_direct_heap_access, and - FLAG_concurrent_inlining inside compiler/ with OptimizedCompilationInfo::is_concurrent_inlining() (or derived values). Bug: v8:7790 Change-Id: I64818e0e1004dded08c784ef1c4bdfd2af990a59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843345 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74166}
-
Jakob Gruber authored
.. which used to be implemented by calling BooleanValue eagerly on all seen heap objects during serialization. 1) it's wasteful to call this on every object, 2) this was blocking conversion of HeapObjectRefs to not require main-thread serialization. This CL replaces the old pattern by a thread-safe TryGetBooleanValue method, which may fail in some cases (e.g. when trying to read into a HeapNumber). Bug: v8:7790 Change-Id: I9d4ab7725231adce0b488c4c08c1f4bac78ce3c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839557 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74165}
-
Jakob Gruber authored
.. by locking the MapUpdater lock during MapData construction. Note this only applies to basic MapRef/MapData construction. Some methods, in particular MapRef::SerializeFoo methods, are not yet background-serializable in general and require more work. Bug: v8:7790 Change-Id: I473e78c82012ab6abc5a0633a4d34c4a40a3fb77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839553 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#74164}
-
- 24 Apr, 2021 1 commit
-
-
Daniel Lehmann authored
This is the second CL in a line of two (see crrev.com/c/2835237) to bring write-protection to the WebAssembly code space. The previous CL changed the page permissions from W^X (only either writable or executable can be active, but never both) to write-protection (due to concurrent execution in the main thread). However, write-protection still did not work, because in several places the code space is modified without properly switching it to writable beforehand. This CL fixes --wasm-write-protect-code-memory such that it can now be enabled again (with potentially high overhead due to frequent page protection switches). For that, it adds the missing switching to writable by adding {NativeModuleModificationScope} objects (similar to the already existing {CodeSpaceWriteScope} objects for Apple M1 hardware). This CL also fixes a race condition between checking for the current writable permission and actually setting the permission, by protecting the counter of currently active writers with the same lock as the {WasmCodeAllocator} itself. (Before multi-threaded compilation, this was not necessary.) Finally, this CL also changes the {Mutex} protecting the {WasmCodeAllocator} to a {RecursiveMutex} because it can be requested multiple times in the call hierarchy of the same thread, which would cause a deadlock otherwise. Since {TryLock()} of a {RecursiveMutex} never fails, this also removes the (now failing) DCHECKs. R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11663 Change-Id: I4db27ad0a9348021b0b663dbe88b3432a4d8d6b5 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2835238 Commit-Queue: Daniel Lehmann <dlehmann@google.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74163}
-
- 23 Apr, 2021 5 commits
-
-
Milad Fa authored
This test produces different outputs when compiled with gcc. It is currently failing on PPC using gcc-8, it also has failed on riscv: https://github.com/riscv/v8/issues/174 I have also tested it with gcc-10 on x64 and it still fails. The line numbers seem to be different when compiled with gcc instead of clang. As a workaround we can force the usage of macros in one line to assure outputs are the same on either compiler. Change-Id: I36a05d0dc62dfe66bdfcf177422836cb231284b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2844666Reviewed-by: Anton Bikineev <bikineev@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#74162}
-
Michael Achenbach authored
Change-Id: I2618874ebf8f963f669901e55ea772413160b304 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848475Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74161}
-
Almothana Athamneh authored
Bug: chromium:934932 Change-Id: I9e7940b645cfad8da40950de86c2a5a7feedccff Cq-Include-Trybots: luci.v8.try:v8_fuchsia_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846894Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Cr-Commit-Position: refs/heads/master@{#74160}
-
Almothana Athamneh authored
Create 32 bit versions of V8 Clusterfuzz Linux64 ASAN no inline - release builder and V8 Clusterfuzz Linux64 ASAN - debug builder. Bug: chromium:1196595 Change-Id: Id6e3e4d5073b824828318a61be17d7e25e30dd8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843812Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Cr-Commit-Position: refs/heads/master@{#74159}
-
Ulan Degenbaev authored
Change-Id: Ib6036e38a145153e865059f1aeccc5cdc8c9e840 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848471Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74158}
-