- 20 Sep, 2019 10 commits
-
-
Joshua Litt authored
This cl adds support for top level await to d8, but still does not allow top level await through parsing. Unfortunately, due to that restriction this cl has no automated tests, but I added a 'top-level-await' variant and manually confirmed it passes locally. Bug: v8:9344 Change-Id: I3528442768107f5ad1ed1e9e947cfceae91c0cc6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808483 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63909}
-
Seth Brenith authored
If we can read an object's Map pointer but not any data from the Map itself, we may still be able to accurately describe the object's type if the Map pointer matches one of the known Maps from the snapshot. GetObjectProperties uses that data in one of two ways: - If it is sure that the Map pointer matches a known Map, then it uses the type from that Map and continues as if it read the type normally. - If the Map pointer is at the right offset within a heap page to match a known Map, but the caller didn't provide the addresses of the first pages in Map space or read-only space, then the type of that Map is just a guess and gets returned in a separate array. This gives the caller the opportunity to present guessed types to the user, and perhaps call again using the guessed type as the type hint. Bug: v8:9376 Change-Id: I187f67b77e76699863a14534a9d635b79f654124 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63908}
-
Sathya Gunasekaran authored
This reverts commit d7b67ce2. Reason for revert: broke tsan https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8901789268326050304/+/steps/Check/0/logs/enumeration-order/0 Original change's description: > [Context] Add a bit flag to indicate if extension might exist > > Checking the bit flag instead of comparing pointers should improve performance. > This will also allow us to remove the extension slot in Context and save memory. > > Bug: v8:9744 > Change-Id: I7ab9feeadfb934955798d877d13bc0e1d78a191c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814918 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63906} TBR=ulan@chromium.org,leszeks@chromium.org,victorgomes@google.com Change-Id: I3d2261e24c9c7da5f5a1d49803361bc6f0770330 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816514Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#63907}
-
Victor Gomes authored
Checking the bit flag instead of comparing pointers should improve performance. This will also allow us to remove the extension slot in Context and save memory. Bug: v8:9744 Change-Id: I7ab9feeadfb934955798d877d13bc0e1d78a191c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814918 Commit-Queue: Victor Gomes <victorgomes@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63906}
-
Ana Peško authored
This CL enables regexp interpreter and tier-up to the compiler after one execution by setting the --regexp-tier-up flag to true by default. The number of times a regexp is interpreted before tiering-up is controlled by the --regexp-tier-up-ticks flag which is already set to 1 by default. Change-Id: I79ff7fcd159f50f2f5351b339d8ffb21af039a86 Bug: v8:9566 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816501Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Ana Pesko <anapesko@google.com> Cr-Commit-Position: refs/heads/master@{#63905}
-
Clemens Hammacher authored
The predictable platform can make tasks deadlock if the spawning task is holding a lock that the spawn task also wants to take. This is because the spawned task is just executed immediately within the "context" of the spawning task. The wasm async compile tests deadlock because the {BackgroundCompileTask}s hold the shared {BackgroundCompileToken} (reader lock) while spawning new tasks via {OnBackgroundTaskStopped} -> {RestartBackgroundTasks}. The new tasks might want to cancel compilation via {BackgroundCompileToken::Cancel}, which takes the writer lock and hence deadlocks. This can not happen on any other platform, since tasks are not nested that way. R=ahaas@chromium.org Bug: v8:9760 No-Try: true Change-Id: I9fc34d5de386aa5c6fdd64a1570fddcff872ec95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816502Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63904}
-
Clemens Hammacher authored
With --wasm-far-jump-table, it will be possible to create 10k (and more) modules in one process. So far, we hit the virtual address space limit around 1k modules, because each module makes a reservation of {kMaxWasmCodeMemory} upfront. After this change, each module will only reserve the estimated needed code size (if --wasm-far-jump-table is set). The test is carefully optimized to not execute too much code in the loop, so it can still run in simulators in reasonable time. Note that the time for actually compiling the module is spent in C++, which is fast in simulator builds. R=mstarzinger@chromium.org Bug: v8:9477, v8:9651 Change-Id: If74a825d272a65b82ca5433cb648b6a2271872e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1811038 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63903}
-
Pierre Langlois authored
The CPURegister class has an additional "type" field to represent an invalid register while the cross-platform RegisterBase class uses -1 as a register code. For consistency and to avoid potential bugs from confusing x0 and `CPURegister::no_reg()`, use -1 as a register code as well in CPURegister. Change-Id: I1a36230091433bc854a5966f36e3c25e33a406c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813746Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#63902}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/050608e..9417d7b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2ad5356..535cd16 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c6be56e..7735f52 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ie3a7b8566ff031dc64dbd774ef3bd81947eb86ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814282Reviewed-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@{#63901}
-
Dmitry Gozman authored
This makes it possible to plumb string representation of stack trace id across various channels, e.g. for network requests. Drive-by: extracted class V8DebuggerId, which encapsulates operations with pair<int64_t, int64_t>. Bug: chromium:988842 Change-Id: I348c91390a85bf07c746d1b1c4a7775f44c7d769 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725193 Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63900}
-
- 19 Sep, 2019 19 commits
-
-
Frank Tang authored
1. Add StringListFromIterable based on https://tc39.es/proposal-intl-list-format/#sec-createstringlistfromiterable 2. Adjust other parts to sync with the new version. Bug: v8:9747 Change-Id: I14202f2963463e6a3e9816209f087bfe8e73cb91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809902 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#63899}
-
Igor Sheludko authored
This is a reland of 6f9b2bd4 We must load JSTypedArray::base_pointer in TurboFan as tagged value otherwise this value may become stale pointer after GC. Original change's description: > [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly > > On-heap typed arrays contain HeapObject value in |base_pointer| field > and an offset in |external_pointer| field. When pointer compression is > enabled we want to combine decompression with the offset addition. > In order to do that we add an isolate root to the external_pointer value > and therefore the data pointer computation can is a simple addition of > a (potentially sign-extended) |base_pointer| loaded as Tagged_t value > and an |external_pointer| value. > > Bug: v8:9706 > Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63874} Bug: v8:9706, chromium:1005599 Cq-Include-Trybots: luci.chromium.try:gpu-fyi-try-win10-nvidia-rel-64 Change-Id: I7bbd2a439306cdd11f2bb0dab5863498624d9740 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813744Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63898}
-
Georg Neis authored
- Check validity of node id in Node constructor. - Turn overflow check in NextNodeId() into debug check only, since that is not checking the interesting overflow anyway. - Increase width of Use::InlineCountField to use all available bits. Bug: chromium:1003286 Change-Id: I59af68e29a466e151f7048e1f15bd56d3fa58e5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813019 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63897}
-
Clemens Hammacher authored
The {code_table_} only contains entries for the declared functions, and is indexed by a slot index. The {PatchJumpTableLocked} and {PatchJumpTablesLocked} functions on the other hand expected a function index (offset by the number of imported functions). From that it computes the slot index again. This translation was missing in one place. This CL fixes this by directly passing the slot index instead of the function index to these methods. In all locations, we computed the slot index anyway for addressing the code table. Drive-by: Use more unique_ptr for managing the {code_table_}. This avoids ever having to store raw pointers. R=ahaas@chromium.org Bug: v8:9477 Change-Id: I81caa53b74da010aee5854879e98e82b7773098b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813742 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#63896}
-
Jakob Kummerow authored
Allocation observers used to set allocation limits with the intention to statistically sample allocations that crossed those points. Those limits had random alignment, but since object allocations are always kTaggedSize-aligned, there is no benefit to having the limit be finer grained. This patch makes sure that the limit is always aligned, which in turn implies that the available space in a linear allocation area is always a multiple of kTaggedSize. Bug: v8:9700 Change-Id: Ib2980b4b8e792cf516cb734b451862c9e2a98029 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813026 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63895}
-
Igor Sheludko authored
... in object literals. Bug: chromium:997056 Change-Id: Ifc210ff53b751c6ef26f16b73c9ac52426a845fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813021Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63894}
-
Toon Verwaest authored
Other array allocation methods in the factory already do the same anyway. Bug: chromium:1003679 Change-Id: I05201dd5d124b530eb6b578abb1486e65d076cc4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1806683Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63893}
-
Jakob Gruber authored
This CL allows us to distinguish between the host- and target OS. The host OS is defined by V8_OS_ macros (e.g. V8_OS_WIN). The target OS is defined by V8_TARGET_OS_ macros (e.g. V8_TARGET_OS_WIN). V8_TARGET_OS_ macros are defined by gn, based on the `target_os` gn variable. If a V8_TARGET_OS_ is set, we also define V8_HAVE_TARGET_OS (this determines fall-back behavior in V8; if it is not defined, we set V8_TARGET_OS_ to equal the equivalent V8_OS_ define). Besides adding the defines, this CL also adds logic to consider the target OS in codegen. Specifically, x64 builds now look at the V8_TARGET_OS_WIN define instead of V8_OS_WIN or _WIN64. This effectively makes cross-compilation to x64 Windows in mksnapshot possible. In future work, we could add similar support for cross-compiling to other platforms such as ia32 Windows. Bug: v8:9736,chromium:803591 Change-Id: I689f3de8c206b743c4bef703f5ade0bba32ce995 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809374Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63892}
-
Dominik Inführ authored
This reverts commit ac3c4fcf. Reason for revert: Tested this CL for backport. Original change's description: > [heap] Disable old-to-new invalidation > > Disable invalidation of old-to-new slots for now. Invalidation doesn't > match behavior of clearing slots directly in the remembered set. > > Bug: chromium:1004365 > Change-Id: Ib6a21457827faafa75be88720c214e5ec483c71b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813028 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63890} TBR=ulan@chromium.org,dinfuehr@chromium.org Change-Id: Id3d210cd970ea7b8e28571b7801b7a395e4f0af3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1004365 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813745Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#63891}
-
Dominik Inführ authored
Disable invalidation of old-to-new slots for now. Invalidation doesn't match behavior of clearing slots directly in the remembered set. Bug: chromium:1004365 Change-Id: Ib6a21457827faafa75be88720c214e5ec483c71b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813028Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#63890}
-
Ulan Degenbaev authored
This complements [Shared]ArrayBuffer::GetBackingStore and allows the embedder to transfer (shared) array buffers using only BackingStores. Bug: v8:9380 Change-Id: I4714a27e06d5be43aef06dc633f11f2d43e4ee75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1811037 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#63889}
-
Ross McIlroy authored
BUG=v8:6949,v8:9396,chromium:1005400 Change-Id: I18f50fc385dd83c8f1c551d1a3dc32714122eb00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813022 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#63888}
-
Nico Weber authored
It's now set by default if is_msan is set. Bug: v8:9715 Change-Id: I84e05ff9a495b666292891a12a3ebe485e4a768a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1810558 Auto-Submit: Nico Weber <thakis@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#63887}
-
Clemens Hammacher authored
This reverts commit 6f9b2bd4. Reason for revert: Fails on nvidia bots, blocking LKGR: https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5005 Original change's description: > [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly > > On-heap typed arrays contain HeapObject value in |base_pointer| field > and an offset in |external_pointer| field. When pointer compression is > enabled we want to combine decompression with the offset addition. > In order to do that we add an isolate root to the external_pointer value > and therefore the data pointer computation can is a simple addition of > a (potentially sign-extended) |base_pointer| loaded as Tagged_t value > and an |external_pointer| value. > > Bug: v8:9706 > Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63874} TBR=ulan@chromium.org,neis@chromium.org,jgruber@chromium.org,ishell@chromium.org,verwaest@chromium.org Change-Id: I901280dd191e78d02969600f775c4f0da796921f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9706 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813027Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63886}
-
Santiago Aboy Solanes authored
There are cases where using VariableList is the way to go, e.g BuildFastLoop. Change-Id: I0dad242b69145b94725ce206938455127aabeb29 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1806684Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#63885}
-
Clemens Hammacher authored
If predictable compilation is requested (via --predictable, --single-threaded, or --wasm-num-compilation-tasks=0), do compile and commit one function at a time. This makes function allocation independent of the timing. R=ahaas@chromium.org Bug: v8:9751, v8:9752 Change-Id: I451a436800c19574caa5e03901bd900d80e53eee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809371Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63884}
-
Ulan Degenbaev authored
This adds an additional V8 API to get the backing store of an array buffer. Unlike the existing API, the backing store comes wrapped in a std::shared_ptr, making lifetime management with the embedder explicit. This obviates the need for the old GetContents() and Externalize() APIs, which will be deprecated in a future CL. Contributed by titzer@chromium.org Bug: v8:9380 Change-Id: I8a87f5dc141dab684693fe536b636e33f6e45173 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807354Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63883}
-
Santiago Aboy Solanes authored
The promise file is too big so I am splitting it in several CLs. TNodified: * AllocatePromiseReaction * AllocatePromiseReactionJobTask * AllocatePromiseResolveThenableJobTask * CreatePromiseResolvingFunctions * CreatePromiseResolvingFunctionsContext * CreatePromiseContext This CL introduces some CASTs that will be deleted once the file is TNodified in full. Bug: v8:6949 Change-Id: Ia3006faa5e9fd0e6fa3c58511772857910326532 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809360 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#63882}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/aae0a7b..050608e Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b4e53c4..2ad5356 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6f9a023..c6be56e Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/faee8bc..2ecd66c TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I2f313f6893d13af4a2e8a351948a8df00a9bc3c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1811148Reviewed-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@{#63881}
-
- 18 Sep, 2019 11 commits
-
-
Irina Yatsenko authored
Added tests for the scenario when the fillers would be evacuated within the new space and when they would be promoted into the old space. The fix is to treat the deferred handles the same as the local ones: call FixStaleLeftTrimmedHandlesVisitor for them. Bug: v8:9739 Change-Id: Idac233716295f53793657164561bb81f8f729065 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809815 Commit-Queue: Irina Yatsenko <irinayat@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63880}
-
Ng Zhi An authored
Change-Id: Icb6a95efd042b116cb495d8bbee1d7261c4f1a05 Bug: v8:9643 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706128 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#63879}
-
Ng Zhi An authored
Quasi Fused Multiply-Add and Quasi Fused Multiply-Subtract performs, on floats, a + b * c and a - b * c respectively. When there is only a single rounding, it is a fused operation. Quasi in this case means that the result can either be fused or not fused (two roundings), depending on hardware support. It is tricky to write the test because we need to calculate the expected value, and there is no easy way to express fused or unfused operation in C++, i.e. we cannot confirm that float expected = a + b * c will perform a fused or unfused operation (unless we use intrinsics). Thus in the test we have a list of simple checks, plus interesting values that we know will produce different results depending on whether it was fused or not. The difference between 32x4 and 64x2 qfma/qfms is the type, and also the values of b and c that will cause an overflow, and thus the intermediate rounding will affect the final result. The same array can be copy pasted for both types, but with a bit of templating we can avoid that duplication. Change-Id: I0973a3d28468d25f310b593c72f21bff54d809a7 Bug: v8:9415 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1779325 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63878}
-
Ng Zhi An authored
Change-Id: Ib07ad54ef20877597dcf50a995a8f8a8e8dcb1c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809816Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63877}
-
Benedikt Meurer authored
Disabling the RegExp compilation cache comes with performance implications, and it doesn't seem to be necessary for debugging. Bug: chromium:992277 Change-Id: I24841f4814bcacb18a3968c37490f201c0c1ccac Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg,v8_linux64_gc_stress_custom_snapshot_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1805637 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63876}
-
Milad Farazmand authored
WASM only supports Little-endian byte ordering and we need a mechanism to reverse the ordering efficiently on Big-endian machines. Up until now this was done using TF graphs within wasm-compiler. The new approach allows for having more machine level optimizations by introducing the new "kSimd128ReverseBytes" opcode which gets executed only on Big-endian machines. Change-Id: I63c6c3c42ca9ff9d9b2af2d45070a70cf1b3cefc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803494Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63875}
-
Igor Sheludko authored
On-heap typed arrays contain HeapObject value in |base_pointer| field and an offset in |external_pointer| field. When pointer compression is enabled we want to combine decompression with the offset addition. In order to do that we add an isolate root to the external_pointer value and therefore the data pointer computation can is a simple addition of a (potentially sign-extended) |base_pointer| loaded as Tagged_t value and an |external_pointer| value. Bug: v8:9706 Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63874}
-
Dominik Inführ authored
We see crashes in the wild, however the minidump does not contain enough information for properly investigating this. This is temporary code that should be deleted as soon as possible. Bug: chromium:1004365 Change-Id: I25e119d891e03f980d63f5d559fcb4429b574cb1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809373 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63873}
-
Mike Stanton authored
The serialization step in the pipeline gets an initial zone, and thus far, it's allocated all of it's hinting information in that zone. However, much of this comes from stepping into calls and walking the bytecode of the called function. Once we finished recursing into a call, we should be able to throw all those hints away -- they've served their purpose, and the "output" of their work is a set of new objects made visible to the broker. Therefore, we should create and destroy a child zone. On a run of typescript, this reduces absolute max (high water mark) allocation of the serialization phase from 10 MB to 5 MB. Bug: v8:7790 Change-Id: Icbb35abed28b1a924328541df82be23594152a8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800570Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#63872}
-
Toon Verwaest authored
This fixes the issue highlighted in https://chromium-review.googlesource.com/c/v8/v8/+/1803236. Change-Id: Iea2d6c4f9585a56d017f2cb1eb8e23b52de1f795 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807356 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63871}
-
Michael Starzinger authored
This introduces {GetContainingWasmFunction} to replace the above method, since calculating offsets into the wire bytes is independent of the concrete module object and hence only needs the shared decoded module. R=clemensh@chromium.org BUG=v8:6847 Change-Id: I145d527506289686653979dbb135480cc42ea4c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809369 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63870}
-