- 12 Oct, 2018 17 commits
-
-
Georg Neis authored
Bug: v8:7790 Change-Id: Ice64279a94b4f25151c1b35da1f3c9c1117d3c80 Reviewed-on: https://chromium-review.googlesource.com/c/1270584 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56600}
-
Georg Neis authored
As part of the standard objects serialization, collect the identities of the Array prototype and the Object prototype from all native contexts. This information is then be consulted at compile time instead of having to call Isolate::IsInAnyContext (which accesses the heap). Bug: v8:7790 Change-Id: I26a8271afadfce243a8032e4a012f249ce3c2a60 Reviewed-on: https://chromium-review.googlesource.com/c/1275815 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Mike Stanton authored
Yesterday I added a call to memmove in CSA for pointer arrays when they are in new space and the concurrent marker isn't running (protected by mask kPointersFromHereAreInteresting, CL here: https://chromium-review.googlesource.com/c/v8/v8/+/1243104/12). The bug was that I didn't emit the check if dealing with a SMI array. However, the GC subsystem at that point doesn't distinguish between SMI and OBJECT FixedArrays. This fix brings the CSA code in line with that. R=ulan@chromium.org Bug: v8:8294 Change-Id: I9eb033c358911e8337562dbc91af8f0e6fbd2ed3 Reviewed-on: https://chromium-review.googlesource.com/c/1278386Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#56598}
-
Clemens Hammacher authored
We were re-definining the FunctionSig typedef in several places. This CL moves it to value-type.h, since it's a signature over ValueType. R=titzer@chromium.org Bug: v8:8238 Change-Id: Id5e8a55c7e0f98d61235e32a5e6cd12e04d26947 Reviewed-on: https://chromium-review.googlesource.com/c/1278387 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56597}
-
Marja Hölttä authored
BUG=v8:8179 Change-Id: Ie39465ee1b356a33c810bc1fc7e35f985347fb5c Reviewed-on: https://chromium-review.googlesource.com/c/1278389Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#56596}
-
Stephan Herhut authored
This also adds support in the c1 visualizer output generator to resolve splintered live ranges before they have been merged back in. Bug: v8:8238 Change-Id: I61e5f6da2e8b77ca9b42fae9004c77163d11960f Reviewed-on: https://chromium-review.googlesource.com/c/1270817Reviewed-by:
-
Stephan Herhut authored
The register allocator has an optimization that makes it try reuse spill-slots between phi-inputs and assign the same spill slot to a phi output, if possible. Furthermore, if the phi has no immediate register use, the output is kept spilled. With this change, no longer require that a phi input was spilled in an immediate predecessor. Instead, it is good enough if it was spilled at definition. Change-Id: I317b9d5f9a9dda6a47972cdf84dc2627b996f3db Reviewed-on: https://chromium-review.googlesource.com/c/1273053 Commit-Queue: Stephan Herhut <herhut@chromium.org> Reviewed-by:
-
Ross McIlroy authored
Adds support for enqueuing parallel parse / compile tasks for eagerly compiled IIFEs during parsing. If the --parallel-compile-tasks flag is enabled, the parser will pre-parse eager top-level IIFEs and enqueue a task on the compiler dispatcher to do the actual parsing / compilation on a worker thread. Currently we always enqueue the task, but we likely want to only enqueue parallel tasks where the script has multiple IIFEs or a substantial amount of top-level script code before the IIFE to avoid the main thread having to immediately block on the parallel task. This work will be done as a follow-up. BUG=v8:8041 Change-Id: If68d7c374548cabd4ec32f1fb6752da7d6aaae6b Reviewed-on: https://chromium-review.googlesource.com/c/1275354Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56593}
-
Clemens Hammacher authored
This will ensure that the Isolate tear-down sequence runs the destructors even if the first callback already ran. The second callback might never be executed, since it runs on a background thread which might not be executed before tear-down of the Isolate. R=titzer@chromium.org, mlippautz@chromium.org Bug: v8:8208, chromium:893549 Change-Id: Ibc148e71bc06936033c5b0f0e70bbb2b5a8e8094 Reviewed-on: https://chromium-review.googlesource.com/c/1276629Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Hai Dang authored
Bug: v8:7980 Change-Id: I35b24638b5e2995bb6a5cbb5a28d0d186e807ef3 Reviewed-on: https://chromium-review.googlesource.com/c/1278725Reviewed-by:
-
Benedikt Meurer authored
Change the way we start collecting async stack traces by storing the current microtask as a root instead of trying to make sense of the last frame we see. This makes it possible to use the zero cost async stack traces in Node.js as well (where the last JavaScript frame we see is not the actual async function, but some frame related to the main event loop usually). In addition to the benefit that it now works with Node.js, we can also extend the new machinery to look through (almost arbitrary) promise chains. For example this code snippet ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` can be made to also show the async function frame, even though at the point where the stack trace is collected we don't have any async function on the stack. But instead there's a PromiseReactionJobTask as "current microtask", and we can dig into the chained promise to see where the async execution is going to continue and eventually find the await promise in the chain. This also removes the removes the need to allocate `.generator_object` specially during scope resolution. Bug: v8:7522 Ref: nodejs/node#11865 Tbr: ulan@chromium.org Design-Document: bit.ly/v8-zero-cost-async-stack-traces Change-Id: Ib96cb17c2f75cce083a24e5ba2bbb7914e20d203 Reviewed-on: https://chromium-review.googlesource.com/c/1277505 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: -
Toon Verwaest authored
If the outer classifier will end up parsing an arrow parameter list we'd only be in an inner classifier if the outer was already known to be non-simple. Change-Id: I9fdfb5539b3a7989869f7190f0919699fe8e5c90 Reviewed-on: https://chromium-review.googlesource.com/c/1276630Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56589}
-
Shiyu Zhang authored
This is a reland of c285380c Original change's description: > Create a fast path to get migration target when updating map > > During map updating, store the pointer to new map in the > raw_transitions slot of the old map that is deprecated from map > transition tree. Thus, we can get the migration target directly > instead of TryReplayPropertyTransitions when updating map. > > This can improve Speedometer2.0 Elm-TodoMVC case by ~5% on ATOM > Chromebook and ~9% on big-core Ubuntu. > > Change-Id: I56f9ce5183bbdd567b964890f623ef0ceed9b7db > Reviewed-on: https://chromium-review.googlesource.com/1233433 > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56303} Change-Id: Idf0b7716b92a6a15bfe58721c2c34dbd02b31137 Reviewed-on: https://chromium-review.googlesource.com/c/1270261Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> Cr-Commit-Position: refs/heads/master@{#56588}
-
Clemens Hammacher authored
On ia32, we were pinning too many registers, resulting in no unpinned byte registers left (we only have three byte registers since {ebx} is reserved for the root register). It turns out that on most paths, we don't actually need to pin any registers, since {Store} is often the last call for an operation (like any store or set_global). If registers need to be pinned, only pass those that must be kept alive across the {Store}. This allows to compute a more narrow set of pinned registers on demand inside {Store}. Plus minor drive-by changes. R=titzer@chromium.org Bug: chromium:894374, chromium:894307, v8:6600 Change-Id: Ic4d7131784c193dc7a2abf0e504d9973f6d5c5f1 Reviewed-on: https://chromium-review.googlesource.com/c/1275819 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Georg Neis authored
We don't need to store the native context explicitly anymore, the broker already has it. Bug: v8:7790 Change-Id: I1096953e3c56bed9d3a8d7d37b108888ef4ac7ec Reviewed-on: https://chromium-review.googlesource.com/c/1270594 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Jakob Gruber authored
TBR=sigurds@chromium.org Bug: v8:6666 Change-Id: I85dbc33a4baf5fb3775a6f557fc146437e17ab80 Reviewed-on: https://chromium-review.googlesource.com/c/1276430Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56585}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/85ceec4..dbb4fad Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/cd3378c..c8b97e3 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/2fddb95..066e110 Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/6e1868c..9647596 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Ia8e468cdad8510de141672485ce58583613e908b Reviewed-on: https://chromium-review.googlesource.com/c/1278491Reviewed-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@{#56584}
-
- 11 Oct, 2018 23 commits
-
-
Jakob Kummerow authored
The primary purpose of this is to untangle a circular dependency objects.h -> handles.h -> objects.h. Most compilation units only need message-template.h, without the rest of messages.h. Bonus: change the enum to an enum class for improved type safety. Bug: v8:3770 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I8102c55197a450811de2588a68a08e7f99ea6b9e Reviewed-on: https://chromium-review.googlesource.com/c/1272193 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:5751 Change-Id: I17e2a5b489e84edb87805dd49dc144d6503d2c27 Reviewed-on: https://chromium-review.googlesource.com/c/1275146 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
Junliang Yan authored
Port a63987a4 Original Commit Message: This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. to TurboFan. R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ife0aa45b11580f316e657942485907cf78336e4b Reviewed-on: https://chromium-review.googlesource.com/c/1276867 Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56581}
-
Tom Anderson authored
BUG=chromium:894427 R=machenbach Change-Id: I129f512960ffc81b607bcdae1e43ddb94358d1df Reviewed-on: https://chromium-review.googlesource.com/c/1277609Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org> Cr-Commit-Position: refs/heads/master@{#56580}
-
Toon Verwaest authored
We only need to report once that we're in an invalid path for binding patterns and arrow formals. Change-Id: I8c7edc1c2a9f431c98e09725d0534e661db76634 Reviewed-on: https://chromium-review.googlesource.com/c/1276626 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Junliang Yan authored
R=joransiu@ca.ibm.com Change-Id: Ie5d47a3c0bc132ddf01910e0b16fd550d769e1bd Reviewed-on: https://chromium-review.googlesource.com/c/1276866Reviewed-by:
-
Yang Guo authored
If the instance template is not marked as undetectable, we can allow it to be called as a constructor. This broke previously with commit ff056334. R=verwaest@chromium.org Bug: v8:7670 Change-Id: I6ecde33bd7532bea4786b2282efce9060bb76276 Reviewed-on: https://chromium-review.googlesource.com/c/1272579Reviewed-by:
-
Clemens Hammacher authored
Reported here: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20NumFuzz%20-%20TSAN/3108 R=yangguo@chromium.org Bug: v8:8278 Change-Id: I78d13cea592678c1ab73b61fd9738f375df565d0 Reviewed-on: https://chromium-review.googlesource.com/c/1276631Reviewed-by:
-
Maya Lekova authored
Skipping on all platforms, as it started appearing regularly. Bug:v8:8296 NOTRY=true TBR=machenbach@chromium.org Change-Id: Ia43ece07af5ed5f0767fad9651be30b2cd3563f2 Reviewed-on: https://chromium-review.googlesource.com/c/1276633Reviewed-by:
-
Toon Verwaest authored
Now that the preparser doesn't track errors anymore, it also doesn't make sense to prepare the message. Change-Id: Ifc69e67f9220be69812257b0fc18b55097236dbd Reviewed-on: https://chromium-review.googlesource.com/c/1275818 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Maya Lekova authored
NOTRY=true TBR=machenbach@chromium.org Bug: v8:8294 Change-Id: Ib235139087bd6a651dc8bd43c5f9990e0513c7a5 Reviewed-on: https://chromium-review.googlesource.com/c/1276627 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Hannes Payer authored
Change-Id: Idc52e3ed6af13b20569a412e98bae0841d32e009 Reviewed-on: https://chromium-review.googlesource.com/c/1254125 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
It's rarely used, so just using {compiler::WasmGraphBuilder} directly is easier to understand and does not add much to the code length. R=titzer@chromium.org Bug: v8:8238 Change-Id: I8eafaac59295047a8540ebe256f00dff61ddae82 Reviewed-on: https://chromium-review.googlesource.com/c/1276426Reviewed-by: -
Michael Hablich authored
TBR=machenbach@chromium.org NOTRY=true Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I8093d12c3a157bbe2ced667ad26e1e1efe8bb2a4 Reviewed-on: https://chromium-review.googlesource.com/c/1276429 Commit-Queue: Michael Hablich <hablich@chromium.org> Reviewed-by:
Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#56570}
-
Marja Hölttä authored
These test mainly the data structures of JSWeakFactory / JSWeakCell. BUG=v8:8179 Change-Id: I20ffd07c18bbb2e21c69d11aa65d1e245203cc82 Reviewed-on: https://chromium-review.googlesource.com/c/1267939 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#56569}
-
Toon Verwaest authored
Simpliy track arrow-formal-parameters through errors and copy it from binding pattern errors in AccumulateImpl rather than using a separate flag. Change-Id: I8146718f490f3c9a5de3c30dec2aa3218831523f Reviewed-on: https://chromium-review.googlesource.com/c/1275816 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Mike Stanton authored
A new CSA function, MoveElements() does an efficient memmove operation when the ElementsKind or new-space status allows it. A few other TNode cleanups applied in the file, for example, preferring the StoreFixedDoubleArrayHole() function. Change-Id: Ia0848c066eebbbbe321f81afe0cfa7df7567cbb7 Reviewed-on: https://chromium-review.googlesource.com/c/1268235 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56567}
-
Sigurd Schneider authored
Bug: v8:7327 Change-Id: Icb9df07963b2fd6686946713d802e12e1d595e95 Reviewed-on: https://chromium-review.googlesource.com/c/1274087Reviewed-by:
-
Michael Achenbach authored
The tests are scratching at the overall timeout. TBR=mslekova@chromium.org NOTRY=true Change-Id: I817337eff76dcf36306d7f5ceaaef34eea7886d3 Reviewed-on: https://chromium-review.googlesource.com/c/1276385 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
This will allow us to use ts-node to execute tests written in TypeScript. Bug: v8:7327 Change-Id: I0804db1f112448350c5e91135242e6ec6706d231 Reviewed-on: https://chromium-review.googlesource.com/c/1274086 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=titzer@chromium.org TEST=mjsunit/wasm/exceptions-rethrow,unittests/FunctionBodyDecoderTest BUG=v8:8091 Change-Id: If52be505fb9897af1bd59d17d1ab47b33b665be0 Reviewed-on: https://chromium-review.googlesource.com/c/1273050 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Michael Achenbach authored
Bug: v8:8292 Change-Id: I74fd304692e90adfb694b73ecf5e7858e3b66607 Reviewed-on: https://chromium-review.googlesource.com/c/1275814Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
-
Toon Verwaest authored
In the preparser we don't need to worry about adding duplicate error objects to the list, so we can simply unconditionally set the error flag. Restructure the accumulator so we can also guarantee that we're checking the same flag as we're setting. Change-Id: I6a22cae468e77e5c6283c6fe937ca655f73991ac Reviewed-on: https://chromium-review.googlesource.com/c/1275813Reviewed-by:
-
