- 04 Aug, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/edf75c7..b2c431c Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f80ffe3..ce6a663 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/98b332f..6c7b829 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: If97b9c9eb4d56364f94f9e0453ba67b462643505 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335955Reviewed-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@{#69211}
-
- 03 Aug, 2020 21 commits
-
-
Dirk Pranke authored
I tripped over this str/bytes issue as part of bringing up the Chromium build under Python3. Bug: chromium:1112471 Change-Id: I723c7d9df8bcac24c160c549a03dcbd34c1d92f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334222 Commit-Queue: Dirk Pranke <dpranke@google.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#69210}
-
Michael Achenbach authored
No-Try: true Change-Id: If5ed824ad3ea1a2815a0a48ed2668281733ac533 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332603Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Auto-Submit: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#69209}
-
Ng Zhi An authored
x64's implementation of i64x2.shr_s was overwriting the scratch register. kScratchRegister is used to hold the extracted lane of the SIMD register, but in certain cases [0], is also used to back up the value of rcx. When this happens, the supposed backed-up rcx was overwritten (definitely) by each extract lane, so we end up restoring an incorrect value of rcx, leading to an eventual crash in certain benchmarks, when this extracted lane was used as a memory operand (see linked bugs). [0] when register holding the shift value is not rcx, which sarq_cl relies on Bug: v8:10752 Bug: chromium:1111522 Change-Id: Iaf3264e16f94e78bad4290783757f0b722d40411 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334354Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69208}
-
Jakob Kummerow authored
This is a stop-gap solution (while we wait for a proper spec) that lets managed WasmGC objects perform round-trips through JavaScript. On the JavaScript side, they appear as empty/opaque. Bug: v8:7748 Change-Id: I0dd368bc14d622f3ef41871484228267359e9b5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316306 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69207}
-
Shu-yu Guo authored
This reached consensus in the July 2020 TC39: https://github.com/tc39/ecma262/pull/2054 Bug: v8:10769 Change-Id: Iecea1d9d9c9be5c2fbfb820aed2285719c4e6382 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333350 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69206}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7c2575f..edf75c7 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/42e9461..6139217 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I80cf25941086ec9e94f0f5806c8c550ea0210280 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334660Reviewed-by:
-
Clemens Backes authored
After allocating a new code space, we do some initial allocations in the new space (e.g. for the jump table). These allocations are not allowed to fail. If this in indeed what's happening in the linked bug, this CHECK will give fuzzers a chance to find us a reproducer. Drive-by: Introduce {WasmCodeAllocator::kUnrestrictedRegion} to remove magic constants. R=ahaas@chromium.org Bug: v8:1111266 Change-Id: Ia76721653226bd4aa346b89ffab0c80f67892794 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333250 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69204}
-
Marja Hölttä authored
If we cancel the task in the thread where it's supposed to run, task cancelling will always succeed. This simplifies the logic. Bug: v8:10239 Change-Id: I3fb5c93a49c52d958aa947d693700161bc18eee5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332807Reviewed-by:
-
Marja Hölttä authored
The majority of the content is the Atomics.waitAsync implementation which I wrote. "git blame" shows I've touched 123 / 274 lines in futex-emulation.h and 551 / 875 lines in futex-emulation.cc. (Status before https://chromium-review.googlesource.com/c/v8/v8/+/2319989 which was moving code around.) No-Try: True Change-Id: Ib31dc0bb778aed90d5c4c56ccb0e556655ce6946 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332813 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#69202}
-
Liviu Rau authored
Bug: chromium:1112260 Change-Id: I8c225594b48c4c2c69b6fde21ba65f8693e078c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335065 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#69201}
-
Georg Neis authored
... since it's still a valid index. Change-Id: I498ff27898cefa5df752ac0ad73408ce76ac06c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327911 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
Change-Id: I5e31bbce2bfbf0effa2c660a67ec88bcd49d06a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335054 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69199}
-
Ross McIlroy authored
Adds support for non-simple fp aliasing (e.g., Arm) for the fast register allocator. BUG=v8:9684 Change-Id: I6717ef1c6cb4e585fa4b6ea8cea7087e68f441e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300483 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Jakob Gruber authored
A stricter V8-side check to flush out the linked bug. Bug: v8:10460 Change-Id: I20a0026e35719632e90f0a00bc49eb27d81b273b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335061 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
Change-Id: Id545ca00106fb54ee08078177ad7f24842752afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332799Reviewed-by:
-
Dominik Inführ authored
Allow the allocation of large old space objects through LocalHeap::AllocateRaw. OldLargeObjectSpace::AllocateRawBackground will allocate a large object on the background thread. Bug: v8:10315 Change-Id: I9212f0c6770855dbe33490516aae7056987e192d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332804 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69195}
-
Omer Katz authored
reinterpret_cast to std::atomic was missing const. Bug: chromium:1108537 Change-Id: Ib737418bddbef6774deafa9714b0efcf2e3fd07c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332797 Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by:
-
Dominik Inführ authored
LocalHeap::AllocateRaw will be similar to Heap::AllocateRaw and handle all allocations. LocalHeap::AllocateRawOrFail will perform a GC and afterwards retry the allocation in a loop. Bug: v8:10315 Change-Id: I68468962cf9102697aa547b2aa05c7ec6bafd19e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332801Reviewed-by:
-
Dominik Inführ authored
Bug: v8:10315 Change-Id: Ic0ccaa608c9b11258e6923919d3e72d23cedc5c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333249Reviewed-by:
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: Ie296b0bcc6c3b26be5ad54f4558a75250a2f2157 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332232 Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/17f3b1c..7c2575f Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2cd291a..f80ffe3 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b63a569..1078c41 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I17dbc645ac8c8463a4468589277ab4203a5e9279 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2331870Reviewed-by:
-
- 02 Aug, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7f53cfc..17f3b1c Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fd3758a..b63a569 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I7b38ec37acb0cd78f06f714b814072ebf68b63e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2331868Reviewed-by:
-
- 01 Aug, 2020 4 commits
-
-
Ulan Degenbaev authored
Chrome is currently adding a 128-bit V8ContextToken to keep track of V8 contexts across multiple isolates and processes. Having per-isolate token exposed by V8 leads to confusion of these two tokens. This moves v8::Context::Token to v8::metrics::Recorder and changes the corresponding functions: - v8::Context::GetToken => v8::metrics::Recorder::GetContextId - v8::Context::GetByToken => v8::metrics::Recorder::GetContext This CL is purely mechanical and does not change the behaviour. Bug: chromium:1101749 Tbr: clemensb@chromium.org Change-Id: I31bbfa02ebab1c0d91b00f0d08c1b236392d14d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330023 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#69188}
-
Dominik Inführ authored
This reverts commit b354e344. Reason for revert: Clusterfuzz found issues with this CL. Original change's description: > [heap] Refactor allocation observer in AllocationCounter > > Moves accounting of allocation observers into the AllocationCounter > class. This CL removes top_on_previous_step_ for counters that are > increased regularly in the slow path of the allocation functions. > > AdvanceAllocationObservers() informs the AllocationCounter about > allocated bytes, InvokeAllocationObservers() needs to be invoked when > an allocation step is reached. NextBytes() returns the number of bytes > until the next AllocationObserver::Step needs to run. > > Bug: v8:10315 > Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650 > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69170} TBR=ulan@chromium.org,dinfuehr@chromium.org Change-Id: Icd713207bfb2085421fd82009be24a0211ae86da No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332667Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69187}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/65e3fac..7f53cfc TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I934b4eebcf58727531022998657954b718899b99 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333182Reviewed-by:
-
Frank Tang authored
Implement https://github.com/tc39/ecma402/pull/487 Also improve test/intl/toStringTag.js see also: https://github.com/tc39/test262/pull/2712 Bug: v8:10744 Change-Id: I678876aa21f169a8dfcec8e3ce974978a8847fe0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315455Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#69185}
-
- 31 Jul, 2020 13 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/f0fc706..65e3fac Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/9e12121..42e9461 Rolling v8/third_party/aemu-linux-x64: nz3cLclK4lWm6gzvGCOHPQAKJUO8EsMBr7EIUXwS9SEC..TfK3Whl6AfZifLOotcOS_jvckKztERlPvmVyZo16fN0C Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d292e89..2cd291a Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/a58287b..98b332f Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/103247f..a21a4e8 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/2eaa59d..fd3758a TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I218e41dfe1026a7851ed4e0a3ac7fbe924f4f9cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333174Reviewed-by:
-
Ng Zhi An authored
Also add some simple unittests for these functions. Bug: v8:10696 Change-Id: Ic7607780b4eaf275b20d0937bf214846bf51d539 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330806Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69183}
-
Almothana Athamneh authored
This CL also includes changes from https://chromium.googlesource.com/chromium/src/build/+log/483d96..f0fc706 Bug: chromium:1111223 Change-Id: I8ee1297eae93050d7ef615f01b388de982c88014 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328790Reviewed-by:
Liviu Rau <liviurau@chromium.org> Reviewed-by:
-
Ross McIlroy authored
Adds support for tracking register allocations across basic block boundaries to the fast register allocator. For now we still spill on loop headers, and spill when merging register states if the register state isn't exactly the same. BUG=v8:9684 Change-Id: I2aaf992fe8b0a5c698b1e44526951c63aedbe86c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300480 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Some of these functions will be reused by Liftoff. Move them into simd-shuffle for sharing (even though these only apply to ia32 and x64). Bug: v8:10696 Change-Id: Ib83a2fcd443f93f86d7a4c85898205edb8c3925c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330796Reviewed-by:
-
Mythri A authored
If incoming map is deprecated, generate code to migrate the map. Since this involves generating additional code and a call to runtime, we only do this if one of the receiver maps was a migration target when optimizing this function. If not, we deoptimize and discard the optimized code if we see a deprecated map. This is to avoid bailout loops when we see deprecated maps. This change does the following: // We generated code to migrate deprecated maps only if one of the maps // in feedback vector is a migration target. if ( there are migration targets in feedback) { if (checkMaps fails) { if (incoming map is deprecated) { migrate the map checkMaps with the new map } else { bailout } } } else { if (checkMaps fails) bailout; } Bug: v8:10582, v8:9684 Change-Id: I8a04c77ed209dd2fb0300a783d844f2335a678c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292231Reviewed-by:Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
-
Avi Drissman authored
Two of them were in comments; updated them to V8_OS_MACOSX. Two of them were incorrectly in #if statements. Updated them to V8_OS_MACOSX. Bug: chromium:823915, chromium:1105907 Change-Id: Ibfc0f8936dbc8cbf3b05a674e882bbc480d0b4c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2331736Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Avi Drissman <avi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69178}
-
Tobias Tebbi authored
This allows templates to preserve the type of implicit parameters to select a better ovleroad, without generally extending overload resolution to implicit parameters, which could be confusing. Bug: v8:7793 Change-Id: Ie57090a295b0b46d03789829b975fc16e2a9c5b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2329630 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69177}
-
Santiago Aboy Solanes authored
As a note, we are not yet passing this to the background so we only have canonical persistent handles on the main thread. Bug: v8:7790 Change-Id: I15b264cfacc2d5524a3d13f62574a3576bb7e1a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330017 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Not needed in order to prevent use-after-frees. Bug: v8:10315 Change-Id: I7713b2fb39681bb88e60fc7cc417b40430f0c73c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326031Reviewed-by:
-
Dan Elphick authored
This allows the configuration v8_enable_shared_ro_heap and v8_enable_pointer_compression on Linux and Android, although it still defaults to off. When pointer compression and read-only heap sharing are enabled, sharing is achieved by allocating ReadOnlyPages in shared memory that are retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are then remapped into the address space of the Isolate ultimately using mremap. To simplify the creation process the ReadOnlySpace memory for the first Isolate is created as before without any sharing. It is only when the ReadOnlySpace memory has been finalized that the shared memory is allocated and has its contents copied into it. The original memory is then released (with PC this means it's just released back to the BoundedPageAllocator) and immediately re-allocated as a shared mapping. Because we would like to make v8_enable_shared_ro_heap default to true at some point but can't make this conditional on the value returned by a method in the code we are yet to compile, the code required for sharing has been mostly changed to use ifs with ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where a compile error would result due to the absence of a class members without sharing. IsReadOnlySpaceShared() will evaluate CanAllocateSharedPages in the platform PageAllocator (with pointer compression and sharing enabled) once and cache that value so sharing cannot be toggled during the lifetime of the process. Bug: v8:10454 Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
When we are not going to be accessing the heap anymore, we can park the LocalHeap which signals to not wait for this thread when requesting safepoints. There are a couple of places where we want to explicitly allow access to the heap, even though we have previously parked. We use UnparkedScope for those cases. Bug: v8:7790 Change-Id: Ic0acc51fe02af89836226670b828db4aafba4d0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319993 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Dominik Inführ authored
We only use IsParked from the thread that owns the LocalHeap, which is the only thread which mutates state_. So it is safe to read state_ from that thread without a mutex. Bug: v8:10315 Change-Id: I3725ca4c4c4da1c661d7b4f06d295312914b4b52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332168Reviewed-by:
-
