- 04 Oct, 2017 26 commits
-
-
Eric Holk authored
CCalls have significantly less overhead than runtime calls which will improve runtime performance on programs that make lots of transitions between JS and Wasm. Bug: v8:5277 Change-Id: If09dea97f24eb43753847e2b894ebc1ba5168c23 Reviewed-on: https://chromium-review.googlesource.com/688481 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48297}
-
Michael Lippautz authored
This reverts commit 0f5d3ed1. Reason for revert: Needs to consider invalidated slots too. Roll flaking on GPU bots: https://chromium-review.googlesource.com/c/chromium/src/+/700721 Original change's description: > [heap] Separate map space pointers updating from main bulk > > Evacuating and compacting LayoutDescriptor is meta-circular, i.e., we > need the descriptor to iterate the objects that are copied. Separate the > phases to avoid requiring a publishing store for object payloads. > > Bug: v8:6884 > Change-Id: Icc3bb80a938fbd9eec60c79d88ab8fdd9bda0840 > Reviewed-on: https://chromium-review.googlesource.com/700437 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48288} TBR=ulan@chromium.org,mlippautz@chromium.org Change-Id: I854687c5e40541c62a0bcf15ad251afe5ddaa8d1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6884 Reviewed-on: https://chromium-review.googlesource.com/701534Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48296}
-
Jakob Kummerow authored
Bug: v8:6791 Change-Id: Id889823ff2cf20cf504010ffce3283f0d75bf72f Reviewed-on: https://chromium-review.googlesource.com/699420Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48295}
-
Eric Holk authored
This reverts commit 5e76ff5a. Reason for revert: tsan failures - https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/17574 Original change's description: > Reland "[wasm] always allocate memory when guard regions are needed" > > This reverts commit 7cf29d8d. > > Original change's description: > > [wasm] always allocate memory when guard regions are needed > > > > When using trap handlers, memory references do not get any checks inserted. This > > means there is no check for a null memory as happens when the memory size is > > 0. Normally this would be correctly caught as an out of bounds access, since the > > low memory addresses are not normally mapped. However, if they were mapped for > > some reason, we would not catch the out of bounds access. > > > > The fix is to ensure WebAssembly instances always have a guard region even if > > the memory is size 0. > > > > Bug: chromium:769637 > > Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00 > Reviewed-on: https://chromium-review.googlesource.com/695812 > Commit-Queue: Eric Holk <eholk@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48293} TBR=gdeepti@chromium.org,mtrofin@chromium.org,mlippautz@chromium.org,eholk@chromium.org,eholk@google.com,clemensh@chromium.org Change-Id: I52d5354126158a92602b08c48703d562ac95075b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/699599Reviewed-by: Eric Holk <eholk@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48294}
-
Eric Holk (eholk) authored
This reverts commit 7cf29d8d. Original change's description: > [wasm] always allocate memory when guard regions are needed > > When using trap handlers, memory references do not get any checks inserted. This > means there is no check for a null memory as happens when the memory size is > 0. Normally this would be correctly caught as an out of bounds access, since the > low memory addresses are not normally mapped. However, if they were mapped for > some reason, we would not catch the out of bounds access. > > The fix is to ensure WebAssembly instances always have a guard region even if > the memory is size 0. > > Bug: chromium:769637 Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00 Reviewed-on: https://chromium-review.googlesource.com/695812 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48293}
-
Michael Lippautz authored
No-try: true Bug: v8:6886 Change-Id: I994b998e9e5006c6de183328603f3545158bd32c Reviewed-on: https://chromium-review.googlesource.com/700536Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48292}
-
Caitlin Potter authored
Fix an error overwriting the `prototype` property of async generator functions when FLAG_enable_slow_asserts is enabled. Previously, the `initial_async_generator_prototype` field was never written to the native context, and was always undefined. This caused some incorrect runtime behaviour, and would crash when loading the field using the Context::initial_aysnc_generator_prototype accessor when attempting to cast the Undefined oddball to a JSObject. BUG=chromium:771470, v8:5855 R=adamk@chromium.org, verwaest@chromium.org, gsathya@chromium.org Change-Id: I13f2a518c59852bc77c2de1f2468a4eea457609e Reviewed-on: https://chromium-review.googlesource.com/700261Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#48291}
-
Niklas Hambüchen authored
The code in `AsmJsScanner::Next()` checks for both end of input and parse error: if (token_ == kEndOfInput || token_ == kParseError) { return; } but until now the code in the parsing loop only checked for `kEndOfInput`, resulting in an infinite loop on `kParseError`. R=bradnelson@chromium.org, mstarzinger@chromium.org Bug: chromium:771428 Change-Id: I9170f090503590b3b9b949a0d00ab4daef85bf66 Reviewed-on: https://chromium-review.googlesource.com/699994 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48290}
-
Daniel Clifford authored
In the process, also enable support for PACKED_DOUBLE_ELEMENTS arrays. Change-Id: I16dd79276f1023e30b072d45216396533077f53c Reviewed-on: https://chromium-review.googlesource.com/571006 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48289}
-
Michael Lippautz authored
Evacuating and compacting LayoutDescriptor is meta-circular, i.e., we need the descriptor to iterate the objects that are copied. Separate the phases to avoid requiring a publishing store for object payloads. Bug: v8:6884 Change-Id: Icc3bb80a938fbd9eec60c79d88ab8fdd9bda0840 Reviewed-on: https://chromium-review.googlesource.com/700437Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48288}
-
Toon Verwaest authored
This speeds up the json parser by 10-20% Bug: chromium:771227 Change-Id: Ib2392471bdd9ff9041237708cb272229b5ece410 Reviewed-on: https://chromium-review.googlesource.com/700494 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#48287}
-
Ben L. Titzer authored
This CL also removes the v8::internal::wasm::testing namespace, which had methods that were defined in wasm-module.h, moving them to be *ForTesting methods on the corresponding WASM heap objects. R=clemensh@chromium.org Bug: v8:6877 Change-Id: I1b346ec64d93ee3a122b8f7e69772cfe98371754 Reviewed-on: https://chromium-review.googlesource.com/695523Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48286}
-
Georgia Kouveli authored
Bug: v8:6644 Change-Id: I5cd713465563f2dc803b175684bf04a05559e653 Reviewed-on: https://chromium-review.googlesource.com/693239 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48285}
-
Benedikt Meurer authored
This CL addresses a couple of minor issues that were in the way of properly inlining polymorphic constructors calls, i.e. as found in this common pattern using Symbol.species: class A { static get [Symbol.species]() { return this; } clone() { return new this.constructor[Symbol.species](); } } class B extends A { static get [Symbol.species]() { return this; } } function foo(o) { return o.clone(); } foo(new A()); foo(new B()); Here the call to this.constructor[Symbol.species]() is the interesting site. To get this fully inlined, we had to - make sure we don't introduce too many CheckHeapObject eagerly that block later optimizations (instead we try harder to see whether the receiver is already provably a HeapObject), and - also update the new.target of polymorphic JSConstruct nodes, when it refers to the same node as the target that we're specializing to (this way the JSCreate becomes fully inlinable later). This seems to yield a solid 1.5% on the ARES6 ML benchmark (run via the d8 cli runner), which confirms the previous profiled estimation. On the micro-benchmark that specifically measures this feature in isolation we go from testClone: 828 ms. on V8 ToT as of today and testClone: 1439 ms. on V8 6.1 to testClone: 219 ms. which is a 3.7x improvement, on top of the previous ~2x boost that we got from inlining the polymorphic symbol lookup. Bug: v8:6885, v8:6278, v8:6344 Change-Id: Ida7abf683c7879978f181ba7f52a125f4f83ae6f Reviewed-on: https://chromium-review.googlesource.com/700596Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48284}
-
Camillo Bruni authored
This CL speeds up a common pattern found in the React framework: function f(a, b, c) { ... }; let f_bound = f.bind(this, 1); let f_bound2 = f_bound(this, 2); This CL yields roughly a 15x improvement for rebinding a bound function. Change-Id: I4d8580a5bce422af411148bc6b3e4eb287fac9ce Reviewed-on: https://chromium-review.googlesource.com/695206 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48283}
-
Michael Achenbach authored
This ports: https://chromium-review.googlesource.com/c/chromium/src/+/696886 Bug: chromium:692940, chromium:524758 Change-Id: I158d996ff76c354b8a672b085d476e9687205034 Reviewed-on: https://chromium-review.googlesource.com/700455Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48282}
-
Michael Lippautz authored
Reuse existing concurrent marking infrastructure for marking in the atomic pause. Details: - Do not stop concurrent marking when entering the atomic pause. - Start concurrent marking when it was off. This is required for non-incremental MC GCs. - Use atomic marking state in MC. - Transition through grey and avoid white->black. CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Bug: chromium:750084 Change-Id: I9f84661e69beac6254494907bdfe94e865b1e3ab Reviewed-on: https://chromium-review.googlesource.com/690002 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#48281}
-
Ivica Bogosavljevic authored
Add instruction cache flish for wrapper table in module compiler instance builder. This fixes several failures in mjsunit/wasm and mjsunit/asm test suites on some MIPS boards. Bug: Change-Id: Ia8b640ad73a078d29f458d55663606dbbe8e387c Reviewed-on: https://chromium-review.googlesource.com/697807Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Cr-Commit-Position: refs/heads/master@{#48280}
-
Clemens Hammacher authored
Good thing this class is actually being unused. Vector<T> is iterable, so it should just be iterated using a foreach loop. R=mstarzinger@chromium.org Change-Id: Ieb6729e5b1336888989d5ec6128b0782b158b1f7 Reviewed-on: https://chromium-review.googlesource.com/695525Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48279}
-
Ilija Pavlovic authored
Port for: https://chromium-review.googlesource.com/c/v8/v8/+/608975 In code generator for MIPS32, certain instructions are substituted with corresponding macro-instructions. TEST= BUG= Change-Id: I2ac47a785f0ea14c448f727da124dc78ea6c81af Reviewed-on: https://chromium-review.googlesource.com/699998Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Cr-Commit-Position: refs/heads/master@{#48278}
-
Daniel Clifford authored
Change-Id: Id34d21437b3881d829526b89058f26741bee7acc Reviewed-on: https://chromium-review.googlesource.com/695327Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#48277}
-
Marja Hölttä authored
After closer investigation, the crashes / regressions we currently have are not so bad that we couldn't have the flag on. BUG=v8:5516 Change-Id: I1b70cf99de1707d659b2e0abcd3678ec71a530bf Reviewed-on: https://chromium-review.googlesource.com/699997Reviewed-by: Michael Hablich <hablich@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48276}
-
Benedikt Meurer authored
The Object.is builtin provides an entry point to the abstract operation SameValue, which properly distinguishes -0 and 0, and also identifies NaNs. Most of the time you don't need these, but rather just regular strict equality, but when you do, Object.is(o, -0) is the most readable way to check for minus zero. This is for example used in Node.js by formatNumber to properly print -0 for negative zero. However since the builtin thus far implemented as C++ builtin and TurboFan didn't know anything about it, Node.js considering to go with a more performant, less readable version (which also makes assumptions about the input value) in https://github.com/nodejs/node/pull/15726 until the performance of Object.is will be on par (so hopefully we can go back to Object.is in Node 9). This CL ports the baseline implementation of Object.is to CSA, which is pretty straight-forward since SameValue is already available in CodeStubAssembler, and inlines a few interesting cases into TurboFan, i.e. comparing same SSA node, and checking for -0 and NaN explicitly. On the micro-benchmarks we go from testNumberIsMinusZero: 1000 ms. testObjectIsMinusZero: 929 ms. testObjectIsNaN: 954 ms. testObjectIsSame: 793 ms. testStrictEqualSame: 104 ms. to testNumberIsMinusZero: 89 ms. testObjectIsMinusZero: 88 ms. testObjectIsNaN: 88 ms. testObjectIsSame: 86 ms. testStrictEqualSame: 105 ms. which is a nice 10x to 11x improvement and brings Object.is on par with strict equality for most cases. Drive-by-fix: Also refactor and optimize the SameValue check in the CodeStubAssembler to avoid code bloat (by not inlining StrictEqual into every user of SameValue, and also avoiding useless checks). Bug: v8:6882 Change-Id: Ibffd8c36511f219fcce0d89ed4e1073f5d6c6344 Reviewed-on: https://chromium-review.googlesource.com/700254Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48275}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/05cc4b1..7311b74 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/3f41f93..672cabd TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I5663213d2835b02d0ed9c953749cb722b8422a58 Reviewed-on: https://chromium-review.googlesource.com/700015Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#48274}
-
Deepti Gandluri authored
When atomic operations are used in loops, return the correct opcode length for loop assignment. Bug=v8:6842,v8:6532 Change-Id: I306db704d8a0baa5d98c05702360e6dfae11cbfa Reviewed-on: https://chromium-review.googlesource.com/699561Reviewed-by: Brad Nelson <bradnelson@chromium.org> Commit-Queue: Brad Nelson <bradnelson@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#48273}
-
Jakob Kummerow authored
For an improved debugging experience. Bug: v8:6791 Change-Id: Id4f7fea47036e4520e7b24edf34f210b664672bc Reviewed-on: https://chromium-review.googlesource.com/699427Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48272}
-
- 03 Oct, 2017 7 commits
-
-
Anisha Rohra authored
Original Commit Message: In the test-run-wasm and test-run-wasm-64 cctests it is not possible to call runtime functions. To test traps in these cctests we therefore replace the runtime call with a call to a c-callback, followed by a return. This CL fixes the problem that the return did not clean up stack parameters. R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ia6b95141341635b769acf12b82b4524a56b12b94 Reviewed-on: https://chromium-review.googlesource.com/698424Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#48271}
-
Yang Guo authored
I'd like to make sure changes to microtask handling do not break debugging. R=jarin@chromium.org Change-Id: I983bd3340261e472b22b0d5b6cded60b64b19d38 Reviewed-on: https://chromium-review.googlesource.com/691715Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48270}
-
Jaroslav Sevcik authored
Change-Id: I0de0ea0798c39831765bb3c00a00d0df7471bc3b Reviewed-on: https://chromium-review.googlesource.com/695407Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48269}
-
Benedikt Meurer authored
THe change in https://chromium-review.googlesource.com/695108 flushed out an issue with the IC::UpdatePolymorphicIC logic, where we'd try to stay MONOMORPHIC or POLYMORPHIC as long as the internalized name doesn't change. But the calling code already does the internalization for keyed accesses with Strings, so we need to double check that the same combination of (map, handler) is not already in the list, and properly go to MEGAMORPHIC state if there's such a pair already. This seriously tanked the six-speed-object-literals-ext-es5.js benchmark on AWFY. Bug: v8:6367, v8:6278, v8:6344 Change-Id: I90ea88d1fe61c165990c0a10d4a8687ffe351986 Reviewed-on: https://chromium-review.googlesource.com/695307Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48268}
-
Mostyn Bramley-Moore authored
Avoid F5 symbol clash. Bug: chromium:770684 Change-Id: I9e851c1fe5abbdc4d032b7efdd0462c96d0c8ef3 Reviewed-on: https://chromium-review.googlesource.com/696063Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com> Cr-Commit-Position: refs/heads/master@{#48267}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ce6d3d8..05cc4b1 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8ec7b14..3f41f93 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: Ibf166d33a133519e0c4ce36b20a42aa391f48c8b Reviewed-on: https://chromium-review.googlesource.com/696523Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#48266}
-
Alexey Kozyatinskiy authored
In V8Debugger code we don't expect task_id == null, e.g. asyncTaskStartedForStepping will trigger debug break on null as task_id. Let's filter task_id == null out. This issue is originally filed in Node.js: https://github.com/nodejs/node/issues/15464 R=dgozman@chromium.org Bug: none Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Icc9f96105b3c91ee1b102d545a7817f7ee93394c Reviewed-on: https://chromium-review.googlesource.com/695808Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48265}
-
- 02 Oct, 2017 7 commits
-
-
Michael Starzinger authored
This makes sure that helper methods on the {TranslatedState} class stick to the counting scheme used by {OptimizedFrame::Summarize} within the stack-walker. Both now treat {kJavaScriptBuiltinContinuation} as real JavaScript frames. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-770543 BUG=chromium:770543 Change-Id: Icda65a7efb487470d39ebf648767a488ebf2e5f1 Reviewed-on: https://chromium-review.googlesource.com/695123 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48264}
-
Michael Starzinger authored
R=jarin@chromium.org Change-Id: I6f2e70d231d2c28c77bee121e98317f3f506fce4 Reviewed-on: https://chromium-review.googlesource.com/691975 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48263}
-
Michael Starzinger authored
This makes sure the deoptimizer properly materializes heap objects, even when the top-most frame happens to be a stub-frame. Without this step the {arguments_marker} would leak into user-land and most likely be treated as an undefined value. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-769852 BUG=chromium:769852 Change-Id: I4ba17501c5d7e68d1f402b7c2cc5ccb0fb7bfb05 Reviewed-on: https://chromium-review.googlesource.com/691996Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48262}
-
Benedikt Meurer authored
Until now keyed accesses to properties with string or symbol keys were only optimized properly while the IC was monomorphic and would go megamorphic as soon as there's another receiver map, even if the name was still the same (i.e. the same symbol or internalized string). This was a weird performance-cliff, that'll hurt modern code especially because for symbols you can only access them via keyed loads and stores. This CL fixes the state machine inside the ICs to properly transition to POLYMORPHIC state (and stay there) as long as the new name matches the previously recorded name. The FeedbackVector and TurboFan were already able to deal with this and didn't need any updates. On the micro-benchmark from the tracking bug we go from testStringMonomorphic: 429 ms. testSymbolMonomorphic: 431 ms. testStringPolymorphic: 429 ms. testSymbolPolymorphic: 5621 ms. to testStringMonomorphic: 429 ms. testSymbolMonomorphic: 429 ms. testStringPolymorphic: 429 ms. testSymbolPolymorphic: 430 ms. effectively eliminating the overhead for symbols completely, and yielding a 13.5x performance boost. This also seems to yield a 1% improvement on the ARES6 ML benchmark, because it eliminates the KEYED_LOAD_ICs for the Symbol.species lookups. Bug: v8:6367, v8:6278, v8:6344 Change-Id: I879fe56387b4c56203c1ad8ef8cafb6cc4c32897 Reviewed-on: https://chromium-review.googlesource.com/695108Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48261}
-
Mathias Bynens authored
The context is the following proposal to make JSON a subset of JavaScript: https://github.com/tc39/proposal-json-superset There’s interest in performing a side investigation to answer the question of what would happen if we stopped treating U+2028 and U+2029 as `LineTerminator`s *entirely*. (Note that this is separate from the proposal, which just changes how these characters are handled in ECMAScript strings.) This is technically a breaking change, and IMHO it would be wonderful if we could get away with it, but no one really has any data on whether or not we could. Adding this use counter lets us get that data. BUG=v8:6827 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia22e8db1634df4d3f965bec8e1cfa11cc7b5e9aa Reviewed-on: https://chromium-review.googlesource.com/693155 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48260}
-
Michael Lippautz authored
Bug: Change-Id: I2b1ae2f475e780606fa07db2cf861eb2537207d6 Reviewed-on: https://chromium-review.googlesource.com/695223Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48259}
-
Camillo Bruni authored
Change-Id: I3b7e5f4fb9bc6cdad3582e19099fb97b2a0c7cb0 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/684185Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#48258}
-