- 16 Feb, 2018 18 commits
-
-
Michael Achenbach authored
NOTRY=true Bug: v8:7455 Change-Id: Icb82e8196bc16b4c8b0eebb3c5820e6b3d581735 Reviewed-on: https://chromium-review.googlesource.com/924309Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#51336}
-
Michael Achenbach authored
This will enable some fuzzers to alter the thread-pool size. Bug: v8:7455 Change-Id: Ic9c9600cdb3dc50e860dbda8432a23bb20f1dd44 Reviewed-on: https://chromium-review.googlesource.com/924273Reviewed-by:
-
Benedikt Meurer authored
The ES2017 specification contains a so-called "throwaway" promise that is used to specify the behavior of await in terms of PerformPromiseThen, but it's actually not necessary and never exposed to user code. In addition to that, hooking up the promise in await required a context (to refer to the generator object) and two closures for the reject/fulfill handling, which would resume the generator corresponding to the async function. That meant, we had to allocate 4 additional objects for every await. Instead of using a JSPromise plus the callbacks, this CL adds logic to allow PromiseReaction and PromiseReactionJobTask to carry arbitrary payloads and Code handlers. We use this for await to avoid the additional 4 objects mentioned above, and instead just have simple Code handlers that resume the generator (for the async function), either by throwing (in case of a rejection) or by resuming normally (in case of fulfillment). For this to work properly the JSGeneratorObject has to have a link to the outer promise returned by the async function, so that the catch prediction can still figure out what to do in case of promise rejection. This is done by adding a new generator_outer_promise_symbol when the debugger is active, which refers from the generator to the outer promise. With this change the doxbee-async-es2017-native test goes from around 100.54ms to around 82.45ms, which corresponds to a ~18% reduction in execution time. Bug: v8:7253 Change-Id: Iae25b3300bac351c3417be5ae687eff469b0e61f Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/924069Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51334}
-
Erik Luo authored
Bug: chromium:810176 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I330fa0bdf81d0bb926cf6db794736e89c069f8f2 Reviewed-on: https://chromium-review.googlesource.com/907707Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Erik Luo <luoe@chromium.org> Cr-Commit-Position: refs/heads/master@{#51333}
-
Benedikt Meurer authored
Add TurboFan inlining support for the following V8 Extras: - v8.createPromise - v8.rejectPromise - v8.resolvePromise These are used by the streams implementation in Chrome currently, and were previously not inlined into TurboFan, although TurboFan already had all the necessary functionality (namely the JSCreatePromise, JSRejectPromise and JSResolvePromise operators). We might eventually want to use these functions in Node core as well (at least short-term for Node 10), to replace the C++ internal API functions with the same name that are currently being used by parts of Node core. For this to work, the rejectPromise and resolvePromise builtins had to be moved back to CSA, as for JavaScript builtins we still have the policy that the optimizing compiler must not inline them. But that's straight-forward since the CSA has all the necessary functionality available anyways. Bug: v8:7253 Change-Id: I39ab015c379956cd58ace866e17f8ec23b2257b2 Reviewed-on: https://chromium-review.googlesource.com/924146Reviewed-by:
-
Sergiy Byelozyorov authored
TBR=sergiyb@chromium.org No-Try: true Bug: chromium:616879 Change-Id: Id0de15718308b3ed5d5c47be6959513b9a95dc34 Reviewed-on: https://chromium-review.googlesource.com/916762 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#51331}
-
Andreas Haas authored
This flag is the WebAssembly native heap equivalent to FLAG_write_protect_code_memory. R=mstarzinger@chromium.org Bug: v8:7454 Change-Id: Id4f671af2e8676d08599c8c30ce03b00e9d33780 Reviewed-on: https://chromium-review.googlesource.com/924071 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51330}
-
Camillo Bruni authored
Drive-by-fixes: - brief print prototype Bug: v8:7310 Change-Id: I4df82bd76c05ff48a5860bd14cf7711140c0b062 Reviewed-on: https://chromium-review.googlesource.com/923737 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#51329}
-
Camillo Bruni authored
Bug: v8:7310 Change-Id: I13cc97aa138ad95248e1d366bd0d326cbe1a090e Reviewed-on: https://chromium-review.googlesource.com/923736Reviewed-by:
-
Peter Marshall authored
Change-Id: Idf3a38c0750071263c6450a17d311cbab632523c Reviewed-on: https://chromium-review.googlesource.com/924141Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#51327}
-
jgruber authored
Will be needed in a follow-up (the constants cache builder needs to grow arrays in old space). Bug: v8:6666 Change-Id: Ibd911ffd30e2b0f43881e649b5601111d23e4509 Reviewed-on: https://chromium-review.googlesource.com/924068Reviewed-by:
-
jgruber authored
This flag will be used to toggle things for isolate-independent builtins during development. Bug: v8:6666 Change-Id: I8a97f08b3d677a01a2a55a4c6445e71e74471f51 Reviewed-on: https://chromium-review.googlesource.com/924067 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Camillo Bruni authored
Bug: v8:7310 Change-Id: I82e7ada4c0f7e415887a859719eb01bb45fd3012 Reviewed-on: https://chromium-review.googlesource.com/921742Reviewed-by:
-
Peter Marshall authored
Change-Id: I2f2b688b50d8f3b6d5aeb17bb0ed88148660b490 Reviewed-on: https://chromium-review.googlesource.com/924066Reviewed-by:
-
Jakob Kummerow authored
This doesn't enable the warning yet, but adds V8_FALLTHROUGH annotations in enough places so that v8 can build with the warning on on my linux box. Found one real bug (in effect-control-linearizer.cc, https://chromium-review.googlesource.com/c/v8/v8/+/850392/3/src/compiler/effect-control-linearizer.cc#825 ). Bug: chromium:812686 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I3542550b9c24b545641d0f0fc43f28f2780b0ab3 Reviewed-on: https://chromium-review.googlesource.com/911731Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
When decoding a br_table instruction, check each br target only once, even if it appears several times in the break table. Also, only mark the merge points as reached after calling the interface method. This is consistent with the behaviour for br and br_if, and is needed for implementing Liftoff correctly. Drive-by: Remove {BreakTo} method which hides trivial functionality behind a non-trivial method name. Drive-by^2: Remove redundant reachability tests. R=titzer@chromium.org Bug: v8:6600 Change-Id: I3f2678c0a6b801b94065dc3e0d452bc2ff82dd50 Reviewed-on: https://chromium-review.googlesource.com/921581Reviewed-by:Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51321}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/89fa02a..c5c828a TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I5c2b4120f994f8354f92df5d00d36874c6215cc1 Reviewed-on: https://chromium-review.googlesource.com/923522Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#51320}
-
Michael Achenbach authored
Change-Id: I9420be73a48db83b622e40f1c2b0dc4364a8d5d0 Reviewed-on: https://chromium-review.googlesource.com/923120Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#51319}
-
- 15 Feb, 2018 21 commits
-
-
Adam Klein authored
R=gsathya@chromium.org Change-Id: Ia03ec888617a492720c78b6c105323182fec351e Reviewed-on: https://chromium-review.googlesource.com/922784Reviewed-by:
-
Adam Klein authored
Tbr: jarin@chromium.org Change-Id: I17477e2c82398b228a366a3d1fd8eb521dd51eae Reviewed-on: https://chromium-review.googlesource.com/922270 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#51317}
-
Michael Achenbach authored
TBR=easterbunny Change-Id: I22f05b717ecdf4e480d6edc09937f2a69544d9f9 Reviewed-on: https://chromium-review.googlesource.com/922901Reviewed-by:
-
Adam Klein authored
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I5fc71633f2412c2bec3a4363a40da9920a3e25e2 Reviewed-on: https://chromium-review.googlesource.com/922386Reviewed-by:
-
Jakob Kummerow authored
Bug: v8:6791 Change-Id: I43c43d217f00720ab666ff9908555fcd0fffe3b5 Reviewed-on: https://chromium-review.googlesource.com/919566Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#51314}
-
Mathias Bynens authored
This patch makes ECMAScript a syntactic superset of JSON by allowing U+2028 and U+2029 in string literals. Proposal repo: https://github.com/tc39/proposal-json-superset Bug: v8:7418 Change-Id: I7ef4ae6d85854ebc44a66e0eaf789814576832b7 Reviewed-on: https://chromium-review.googlesource.com/921228Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#51313}
-
Andreas Haas authored
The call to isolate_->AdjustAmountOfExternalAllocatedMemory in WasmCodeManager::FreeNativeModuleMemories can cause a GC, which can indirectly call WasmCodeManager::FreeNativeModuleMemories again. It seems that this recursive call can cause memory to be deallocated twice. With this CL we clear the list of owned_memory after all entries were deallocated so that we cannot deallocate them again. I think this CL fixes a crash we saw on ChromeCrash. I don't know how to reproduce the issue though, or how to write a test for it. R=mstarzinger@chromium.org Bug: chromium:812532 Change-Id: I3b66274f9b72919952a4211e984192c0867a6c22 Reviewed-on: https://chromium-review.googlesource.com/921226Reviewed-by:
-
Georg Neis authored
This is a reland of af677f29, fixing an issue with negative indices. Original change's description: > [ic] EmitElementStore: don't miss when hitting new space limit. > > CSA::EmitElementStore used to bail out (IC miss) via > CSA::CheckForCapacityGrow when the capacity hits the new space > limit, causing the store IC to go megamorphic in my example (see > referenced bug). With this CL, we do what TF'ed code does already: > call into Runtime::kGrowArrayElements (in this situation), thus > staying monomorphic. > > Here's a contrived test case: > > //////////////////////// > let x = []; > > function bar() { > for (let i = 0; i < 50000; ++i) x[i] = i; > } > > function foo() { > for (let i = x.length; i < 100e6; ++i) x[i] = i; > } > > bar(); > foo(); > //////////////////////// > > This took about 4s on my machine, now it takes 3s. > > Bug: v8:7447 > Change-Id: I7f268fc55835f363d250613ce0357444a663051c > Reviewed-on: https://chromium-review.googlesource.com/918723 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51297} Bug: v8:7447, chromium:812451 Change-Id: I345b5e5b2437c4f50e42bbd87947630f24cd95eb Reviewed-on: https://chromium-review.googlesource.com/921201 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51311}
-
Toon Verwaest authored
Bug: Change-Id: Ie8b269467c8b1c5e97d1da9879f41319a49d5407 Reviewed-on: https://chromium-review.googlesource.com/911793 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#51310}
-
Toon Verwaest authored
instance_class_name takes up space unnecessarily, and %_ClassOf and class_name implement [[Class]] which isn't part of ES2015+ anymore. Bug: Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8 Reviewed-on: https://chromium-review.googlesource.com/776683Reviewed-by:
-
Joakim Bengtsson authored
In some workloads the Unmapper could reach kMaxUnmapperTasks at which point it wouldn't start any new tasks and not free any more memory until the next major GC. It could lead to a large buildup of memory in the Unmapper. Bug: v8:7440 Change-Id: I23fda67b2e27824c04ac886d7e111bb01188be74 Reviewed-on: https://chromium-review.googlesource.com/913490Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#51308}
-
Michael Starzinger authored
R=rmcilroy@chromium.org Change-Id: I0f6d628e49c1a3e3123c8e6f59f584fd5bb3a0ca Reviewed-on: https://chromium-review.googlesource.com/919064Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51307}
-
Georg Neis authored
This reverts commit af677f29. Reason for revert: Clusterfuzz found an issue. Original change's description: > [ic] EmitElementStore: don't miss when hitting new space limit. > > CSA::EmitElementStore used to bail out (IC miss) via > CSA::CheckForCapacityGrow when the capacity hits the new space > limit, causing the store IC to go megamorphic in my example (see > referenced bug). With this CL, we do what TF'ed code does already: > call into Runtime::kGrowArrayElements (in this situation), thus > staying monomorphic. > > Here's a contrived test case: > > //////////////////////// > let x = []; > > function bar() { > for (let i = 0; i < 50000; ++i) x[i] = i; > } > > function foo() { > for (let i = x.length; i < 100e6; ++i) x[i] = i; > } > > bar(); > foo(); > //////////////////////// > > This took about 4s on my machine, now it takes 3s. > > Bug: v8:7447 > Change-Id: I7f268fc55835f363d250613ce0357444a663051c > Reviewed-on: https://chromium-review.googlesource.com/918723 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51297} TBR=neis@chromium.org,bmeurer@chromium.org Change-Id: I34eef5919cbdef1b35512aa98ac2de0ae5fcc7cc No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7447 Reviewed-on: https://chromium-review.googlesource.com/921121Reviewed-by:
-
Andreas Haas authored
The WasmModuleObjectBuilder was the first interface for streaming compilation of WebAssembly. Over time we realized that the interface is insufficient, and we introduced the WasmModuleObjectBuilderStreaming class, which is used now for streaming compilation. Since the WasmModuleObjectBuilder was never fully functional, I think it is okay to remove it without a deprecation period. R=clemensh@chromium.org, adamk@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia3ac5f150fdad7bc1ad04ba89aee53538d43ce01 Reviewed-on: https://chromium-review.googlesource.com/913614Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#51305}
-
Marja Hölttä authored
Apparently it can happen that the variable to which we're restoring to has a two-byte name corresponding to the one-byte name we expect. Modify the debug-mode name check to allow this. BUG=v8:7428 Change-Id: I94c56a4b2de3c58b50246fecaead332b0f9679b4 Reviewed-on: https://chromium-review.googlesource.com/911801Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/39738e7..89fa02a TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I1e1b8d8fa430e7ecc4ce6fe57de64ff7442245c2 Reviewed-on: https://chromium-review.googlesource.com/920706Reviewed-by:
-
Michael Achenbach authored
Change-Id: Idb8fd2593f65a74f4f8fd71129f9780bfb08219a Reviewed-on: https://chromium-review.googlesource.com/920650Reviewed-by:
-
Michael Achenbach authored
TBR=easterbunny Change-Id: Iac8be5eb68c99ad953960b4776181c4ba305d3b8 Reviewed-on: https://chromium-review.googlesource.com/920767Reviewed-by:
-
Sergiy Byelozyorov authored
R=machenbach@chromium.org NOTRY=true Bug: chromium:616879 Change-Id: Ie732c5432cc0b69a28b4e356d9cead5855d00a7c Reviewed-on: https://chromium-review.googlesource.com/915361 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Michael Achenbach authored
TBR=cbruni@chromium.org NOTRY=true Bug: v8:7438 Change-Id: Ibfd56a095a302782876b57e01325fadd2657d574 Reviewed-on: https://chromium-review.googlesource.com/919007Reviewed-by:
-
Michael Achenbach authored
TBR=easterbunny Change-Id: I9b2ada2fe81319c0344a8b5d416a82d5fa64af17 Reviewed-on: https://chromium-review.googlesource.com/919684Reviewed-by:
-
- 14 Feb, 2018 1 commit
-
-
Georg Neis authored
CSA::EmitElementStore used to bail out (IC miss) via CSA::CheckForCapacityGrow when the capacity hits the new space limit, causing the store IC to go megamorphic in my example (see referenced bug). With this CL, we do what TF'ed code does already: call into Runtime::kGrowArrayElements (in this situation), thus staying monomorphic. Here's a contrived test case: //////////////////////// let x = []; function bar() { for (let i = 0; i < 50000; ++i) x[i] = i; } function foo() { for (let i = x.length; i < 100e6; ++i) x[i] = i; } bar(); foo(); //////////////////////// This took about 4s on my machine, now it takes 3s. Bug: v8:7447 Change-Id: I7f268fc55835f363d250613ce0357444a663051c Reviewed-on: https://chromium-review.googlesource.com/918723 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
