- 15 Oct, 2018 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e270920..9578c43 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I67c5cb1f4f781605098e106289061d4f4e449236 Reviewed-on: https://chromium-review.googlesource.com/c/1279935 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#56620}
-
- 14 Oct, 2018 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e4c7352..e270920 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/94faf32..dd78844 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I7a2eedb4f0271ce281c9722c384add7195e0e38a Reviewed-on: https://chromium-review.googlesource.com/c/1279925 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Reviewed-by:
-
- 13 Oct, 2018 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/dbb4fad..e4c7352 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c8b97e3..5aac72d Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/066e110..94faf32 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I73f0237a1799d01c5dec0df65763300626b19de6 Reviewed-on: https://chromium-review.googlesource.com/c/1279922Reviewed-by:
-
- 12 Oct, 2018 34 commits
-
-
Bill Budge authored
- Adds embedder callback to notify fully tiered compilation is finished, returning a WasmCompiledModule for serialization. - Adds function to pass previously compiled bytes into WASM streaming compilation, for deserialization. - Plumbs this API through StreamingDecoder. Bug: chromium:719172 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ibe376f3a8ccfa90fda730ef4ff6628a1532da45c Reviewed-on: https://chromium-review.googlesource.com/c/1252884Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#56617}
-
Michaël Zasso authored
The dependency is not required to build V8 but Node.js needs it for running mjsunit tests. Refs: https://github.com/nodejs/node-v8/issues/83 Change-Id: Ieb37acb73e5e2fe417c7d9a16c498565839b7a45 Reviewed-on: https://chromium-review.googlesource.com/c/1278166Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56616}
-
Jakob Kummerow authored
This makes it possible for handles.h to #include objects.h, which upcoming changes will need. Bug: v8:3770 Change-Id: I4f500736028668749bb73fb24f9732df757e97d0 Reviewed-on: https://chromium-review.googlesource.com/c/1278487Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#56615}
-
Maya Lekova authored
Bug:v8:8303 NOTRY=true Change-Id: I45da1a1f0f16488610ddabfd0bb88408571fa161 Reviewed-on: https://chromium-review.googlesource.com/c/1278279 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
For the --async-stack-traces we can also look through initial parts of the promise chain that were created by regular Promise#then() calls to walk up to the first async function frame. This addresses the missing support for aforementioned example ```js (async function() { await Promise.resolve().then(() => console.log(new Error().stack)); })(); ``` which now also works. Bug: v8:7522 Change-Id: I574943c1fc6ee4a1bd56f208dce78eb7506c5c4f Reviewed-on: https://chromium-review.googlesource.com/c/1278276Reviewed-by:Maya Lekova <mslekova@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56613}
-
Clemens Hammacher authored
LockGuard is mostly used with Mutex. Since both are defined outside the internal namespace, we often have to write {base::LockGuard<base::Mutex>}. This CL shortens this to {base::MutexGuard} across the code base R=mlippautz@chromium.org Bug: v8:8238 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I020d5933b73aafb98c4b72e3bb2dfd07c979ba73 Reviewed-on: https://chromium-review.googlesource.com/c/1278796Reviewed-by:Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Sathya Gunasekaran authored
When trying to print the scope information for the class fields initializer function, the debugger asks the parser to parse the class literal as a function literal (to get the scope info) ... which doesn't quite work. Instead of adding support for parsing the class literal, we just short cicruit this parsing step by just returning an empty context. This works fine because initializer function doesn't have any variables in it's local scope. The one caveat is that the objects in the scope above this function (like the global) are now missing. This trade off is possibly fine for now, as adding parsing support for class literal to only produce would be a lot of code for not enough use. As a follow up to this change, the devtools UI needs to be updated to handle this empty context cleanly. Currently, it doesn't show the `this` object if no context exists even if the `this` object is correctly passed to the UI from the backend. Bug: v8:5367, v8:8122 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I52965f26241bbf6abdc988783aa0fc44bb36901f Reviewed-on: https://chromium-review.googlesource.com/c/1274268 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56611}
-
Maya Lekova authored
This reverts commit b5800a63. Reason for revert: Proper fix has already landed, see https://chromium-review.googlesource.com/c/v8/v8/+/1278386 Original change's description: > [test] Skpping flaky object-seal test on TSAN > > 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: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56573} TBR=machenbach@chromium.org,mslekova@chromium.org Change-Id: I641aa14c2a5c4a4d1db3cde6048cf355b59e4f7c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8294 Reviewed-on: https://chromium-review.googlesource.com/c/1278795Reviewed-by:
-
Ross McIlroy authored
The memory pressure notification logic wasn't correct and given the current users of the compiler dispatcher aren't posting speculative tasks, it isn't particularly useful. After removing this, the abort logic can also be simplified significantly by removing the non-blocking abort logic. BUG=v8:8041 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I584533b58fb717fdca46cc620822914d6bdb28b8 Reviewed-on: https://chromium-review.googlesource.com/c/1278495Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56609}
-
Maya Lekova authored
Updated the test so that it uses assertPromiseResult, which makes sure that a promise rejection is not swallowed. The change is reflected in the actual async ids, checked in the test. Bug: v8:8300 Change-Id: Ie227ca74a8cf4e0e079809b21c3abc5a5f87c11a Reviewed-on: https://chromium-review.googlesource.com/c/1278388 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56608}
-
Ross McIlroy authored
There was a small race where an idle task could be posted after the compiler dispatcher had aborted and the CancellableTaskRunner had been cancelled. This was causing flakyness on the bots. This fixes this by moving the idle task posting into the same lock block as the notification to the main thread that the background task has completed. BUG=v8:8041 Change-Id: I43ca4cea807bfdfeb13f6d1c4a67a4d8a4f6291f Reviewed-on: https://chromium-review.googlesource.com/c/1278494Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org TEST=unittests/WasmOpcodeLengthTest.Statements BUG=v8:8091 Change-Id: Ia2a01d5c35ace33c9c8a29a8df7b30e3f1e119cc Reviewed-on: https://chromium-review.googlesource.com/c/1278728Reviewed-by:
-
Clemens Hammacher authored
We generally try to use the most specific type, but sometimes we still used LiftoffRegister even though it's statically known that it always holds a GP register. Make these uses use Register directly. Note that the conversion between Register and LiftoffRegister is a noop in Release builds. R=titzer@chromium.org Bug: v8:6600 Change-Id: I1cf9aa727fb6fd71bbc1eed77df5e9d01e35ddee Reviewed-on: https://chromium-review.googlesource.com/c/1278727Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56605}
-
Ulan Degenbaev authored
This fixes a potential data race that can happen when a freshly allocated layout descriptor is set on an existing map while the concurrent marker is using the map to visit an object. Change-Id: If8ff1c9368b24beb15fefe4a78a21e0f0784d2e8 Reviewed-on: https://chromium-review.googlesource.com/c/1278726Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Hai Dang authored
Change-Id: Iec5e6baff16260317f693188b01230ab0c2bb86f Reviewed-on: https://chromium-review.googlesource.com/c/1278809Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#56603}
-
Clemens Hammacher authored
This class was defined in function-body-decoder.cc, but it's not an implementation of function body decoding, but rather the interface between the decoder and the WasmGraphBuilder. Hence move it out to its own file. R=titzer@chromium.org, mstarzinger@chromium.org Bug: v8:8238 Change-Id: Ib9bf47e90a3683f578b30b6de74d01da81b2be93 Reviewed-on: https://chromium-review.googlesource.com/c/1278391 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#56602}
-
Marja Hölttä authored
It's obsolete, see https://web.archive.org/web/20161216045840/http://wiki.ecmascript.org/doku.php?id=harmony:egal Change-Id: I58a7aa8fcf5dff7e76e5603d42aeb53a994c313d Reviewed-on: https://chromium-review.googlesource.com/c/1278394Reviewed-by:
-
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:
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:
-
Marja Hölttä authored
BUG=v8:8179 Change-Id: Ie39465ee1b356a33c810bc1fc7e35f985347fb5c Reviewed-on: https://chromium-review.googlesource.com/c/1278389Reviewed-by:
-
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:
-
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:
-
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:
-
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:
-
- 11 Oct, 2018 3 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:
-
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}
-
