- 11 Sep, 2017 10 commits
-
-
Clemens Hammacher authored
Cleanup before enabling the presubmit check: https://chromium-review.googlesource.com/c/v8/v8/+/657104 Bug: v8:6811 R=ahaas@chromium.org CC=mstarzinger@chromium.org Change-Id: Ifbf9210464b46dfdb5e04fbedc41d30e11536f74 Reviewed-on: https://chromium-review.googlesource.com/657422Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47943}
-
Benedikt Meurer authored
The Typer put the wrong type on String#index and String#lastIndexOf builtins, with an off by one on the upper bound. Bug: chromium:762874 Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932 Reviewed-on: https://chromium-review.googlesource.com/660000Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47942}
-
Andreas Haas authored
In the test case the module contained a memory which got exported by the name 'main'. The fuzzer crashed when it tried to cast the memory to a function to execute it. This CL checks that 'main' is a function before doint the cast. R=clemensh@chromium.org Bug: chromium:763349 Change-Id: I9a21413c8038a7547f8b59057afea2870b15499a Reviewed-on: https://chromium-review.googlesource.com/659978Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#47941}
-
Benedikt Meurer authored
TurboFan wasn't able to inline calls to Array.prototype.push which didn't have exactly one parameter. This was a rather artifical limitation and was mostly due to the way the MaybeGrowFastElements operator was implemented (which was not ideal by itself). Refactoring this a bit, allows us to inline the operation in general, independent of the number of values to push. Array#push with multiple parameters is used quite a lot inside Ember (as discovered by Apple, i.e. https://bugs.webkit.org/show_bug.cgi?id=175823) and is also dominating the Six-Speed/SpreadLiterals/ES5 benchmark (see https://twitter.com/SpiderMonkeyJS/status/906528938452832257 from the SpiderMonkey folks). The micro-benchmark mentioned in the tracking bug (v8:6808) improves from arrayPush0: 2422 ms. arrayPush1: 2567 ms. arrayPush2: 4092 ms. arrayPush3: 4308 ms. to arrayPush0: 798 ms. arrayPush1: 2563 ms. arrayPush2: 2623 ms. arrayPush3: 2773 ms. with this change, effectively removing the odd 50-60% performance cliff that was associated with going from one parameter to two or more. Bug: v8:2229, v8:6808 Change-Id: Iffe4c1233903c04c3dc2062aad39d99769c8ab57 Reviewed-on: https://chromium-review.googlesource.com/657582Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47940}
-
Ivica Bogosavljevic authored
Fix 408f252b Bug: Change-Id: Ibed235d76ceb9a6adc818a5e06b1ba28fe365cba Reviewed-on: https://chromium-review.googlesource.com/659619Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com> Cr-Commit-Position: refs/heads/master@{#47939}
-
Franziska Hinkelmann authored
If Coverage goes out of scope, ScriptData, FunctionData, or BlockData still rely on Coverage's coverage_. Make coverage_ a shared_ptr owned by all four classes. Bug: Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ifab5d05184cc5db0fd0a935254b967286295e63f Reviewed-on: https://chromium-review.googlesource.com/657381Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#47938}
-
Franziska Hinkelmann authored
Bug: v8:5933 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: If7d69844a309285ff53edb38688c3c647217fea2 Reviewed-on: https://chromium-review.googlesource.com/657379Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#47937}
-
Benedikt Meurer authored
It's quite common today to use Function#apply together with typed arrays, for example to construct a String from character codes (or code points) within a Uint8Array or Uint16Array, i.e. String.fromCharCode.apply(undefined, uint8array) is seen quite often on the web. But there are other interesting cases like Math.max.apply(undefined, float64array) to compute the maximum value in a Float64Array, which is definitely not the fastest implementation, but quite convenient and readable. Unfortunately these cases hit the super-slow-path of the Function#apply machinery in V8 currently, because Function#apply doesn't have any fast-path for TypedArrays. This CL adds a proper fast-path to CreateListFromArrayLike to the ElementsAccessor, which can be used as long as the typed array that's passed wasn't neutered. With this fast-path in place, the performance on the micro-benchmark mentioned in the issue improves from stringFromCharCode: 6386 ms. stringFromCodePoint: 8752 ms. to stringFromCharCode: 1932 ms. stringFromCodePoint: 4262 ms. which corresponds to a 2.0x-3.3x improvement. Bug: v8:2435 Change-Id: I4d39666e53644b11d5856982b005928e26f296fe Reviewed-on: https://chromium-review.googlesource.com/657405Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47936}
-
Jeremy Roman authored
It is legal to stringify other kinds of values, like strings and numbers. Since Local<Object> is convertible to Local<Value>, this is unlikely to break callers. Bug: v8:6810 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ie8e97c86308d62cdf0a2a17490a6e20de58fc76e Reviewed-on: https://chromium-review.googlesource.com/657633Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jeremy Roman <jbroman@chromium.org> Cr-Commit-Position: refs/heads/master@{#47935}
-
Jaroslav Sevcik authored
[turbofan] Reland^3 "Polymorphic inlining - try merge map check dispatch with function call dispatch." This reverts commit ae28e0cf. Bug: chromium:758096 Change-Id: I6541bd1ba46cd5dfb942ed3f3d382e047fb1f3e6 Reviewed-on: https://chromium-review.googlesource.com/657401Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47934}
-
- 09 Sep, 2017 1 commit
-
-
Anisha Rohra authored
Port 9e995e12 Port 408f252b Up to now, each architecture defined all Register types as structs, with lots of redundancy. An often found comment noted that they cannot be classes due to initialization order problems. As these problems are gone with C++11 constexpr constants, I now tried making Registers classes again. All register types now inherit from RegisterBase, which provides a default set of methods and named constructors (like ::from_code, code(), bit(), is_valid(), ...). This design allows to guarantee an interesting property: Each register is either valid, or it's the no_reg register. There are no other invalid registers. This is guaranteed statically by the constexpr constructor, and dynamically by ::from_code. I decided to disallow the default constructor completely, so instead of "Register reg;" you now need "Register reg = no_reg;". This makes explicit how the Register is initialized. I did this change to the x64, ia32, arm, arm64, mips and mips64 ports. Overall, code got much more compact and more safe. In theory, it should also increase performance (since the is_valid() check is simpler), but this is probably not measurable. R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2e87efc8790290c64fd6c0a2d093326710b30ed3 Reviewed-on: https://chromium-review.googlesource.com/658065Reviewed-by: Jaideep Bajwa <bjaideep@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47933}
-
- 08 Sep, 2017 24 commits
-
-
Sathya Gunasekaran authored
Bug: v8:5967 Change-Id: I10388495158fe72ff06cc0f9f9a7b9522705f6e6 Reviewed-on: https://chromium-review.googlesource.com/658301Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#47932}
-
Alexander Timokhin authored
We should add this define to external_config because it is used in public include v8.h (e.g.: https://cs.chromium.org/chromium/src/v8/include/v8.h?l=272&rcl=5cd6565d5ad06a8cb5a1d9d502d15a54e4fa5bbe) Change-Id: Idf29830a43f348fbf658fada0036c65ab410b155 Reviewed-on: https://chromium-review.googlesource.com/657397Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#47931}
-
Clemens Hammacher authored
Even though we were generating additional arguments with default value in the case that the caller was not providing enough, we then passed the original pointer, leading to potential out-of-bounds accesses. R=ahaas@chromium.org Bug: chromium:763294,chromium:763297 Change-Id: Id18622d0d40e0408e26a5fc6f97494b5f9e18d17 Reviewed-on: https://chromium-review.googlesource.com/657699Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47930}
-
Ben Smith authored
TSAN finds data races in generated JavaScript code that use access the SharedArrayBuffer backing store racily. These are races, but they are OK in the sense that the JavaScript memory model allows for the potential bad behavior they could introduce (e.g. potentially tearing reads). Relaxed atomics could be used here instead, but that could introduce performance regressions. This change adds TSAN annotations to the TypedArray reads/writes to prevent TSAN from warning about them. Bug: chromium:722871 Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36 Reviewed-on: https://chromium-review.googlesource.com/656509 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47929}
-
Benedikt Meurer authored
The previous %StringCharCodeAt runtime entry (and the inlined intrinsic) are obsolete and not used anymore (except in dedicated tests for this runtime function), so remove it. And rename the %StringCharCodeAtRT function, which is actually used to %StringCharCodeAt instead to have a consistent naming scheme for runtime fallbacks. Bug: v8:5049 Change-Id: I619429ef54f6efea61fc51ab9ed1d5cfe4417f99 Reviewed-on: https://chromium-review.googlesource.com/657719 Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47928}
-
Michael Starzinger authored
R=mvstanton@chromium.org BUG=v8:6409 Change-Id: I9252055a395287381d2646fedc59c8c376333694 Reviewed-on: https://chromium-review.googlesource.com/652469Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47927}
-
Clemens Hammacher authored
This is a cleanup for a presubmit check that might get enabled soon: https://chromium-review.googlesource.com/c/v8/v8/+/657104 R=ahaas@chromium.org CC=mstarzinger@chromium.org Change-Id: Id431f2d4e8fcbb88a777b63e3fb136fa8ceac70a Reviewed-on: https://chromium-review.googlesource.com/657400 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47926}
-
Camillo Bruni authored
Change-Id: I61d9e2555fa6063e6e047f7cadb9fbcf4cdba312 Reviewed-on: https://chromium-review.googlesource.com/654869 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#47925}
-
Marja Hölttä authored
This reverts commit de9269f3. Something's still wrong in the encoding handling (see bug). Bug: chromium:763106 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icd19dd42b84b9d090e191375a2942b9941110bcf Reviewed-on: https://chromium-review.googlesource.com/657386 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#47924}
-
Anna Henningsen authored
This can be useful when there may be multiple callbacks attached by code that's not directly tied to a single isolate, e.g. working on a per-context basis. This also allows rephrasing the global non-isolate APIs in terms of this new API, rather than working around it inside `src/heap`. TBR=hpayer@chromium.org Bug: Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2e490ec40d1a34ea812f25f41ef9741d2116d965 Reviewed-on: https://chromium-review.googlesource.com/647548Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47923}
-
Jaroslav Sevcik authored
The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: I35a69e690a0647e1e6092bf881007198b252d3e8 Reviewed-on: https://chromium-review.googlesource.com/657577Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47921}
-
Franziska Hinkelmann authored
JavaScript is a dynamically typed language. But most code is written with fixed types in mind. When debugging JavaScript, it is helpful to know the types of variables and parameters at runtime. It is often hard to infer types for complex code. Type profiling provides this information at runtime. Node.js uses the inspector protocol. This CL allows Node.js users to access and analyse type profile for via Node modules or the in-procress api. Type Profile helps developers to analyze their code for correctness and performance. Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing Add `takeTypeProfile` to the inspector protocol. It returns a list of TypeProfileForScripts, which in turn contains the type profile for each function. We can use TypeProfile data to annotate JavaScript code. Sample script with data from TypeProfile: function f(/*Object, number, undefined*/a, /*Array, number, null*/b, /*boolean, Object, symbol*/c) { return 'bye'; /*string*/}; f({}, [], true); f(3, 2.3, {a: 42}); f(undefined, null, Symbol('hello'));/*string*/ Bug: v8:5933 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d Reviewed-on: https://chromium-review.googlesource.com/508588 Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47920}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: I4e2108beee792e54d4ff54c36fd326a058272b73 Reviewed-on: https://chromium-review.googlesource.com/657179Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47919}
-
Yuki Shiino authored
Map::kBitFieldOffset should be loaded as a byte data. This patch fixes the loading instruction of Map::kBitFieldOffset in lazy accessors. Bug: v8:6795, v8:6156 Change-Id: I8fbc88ed44fb43a24335fc81f75b7199ca80212c Reviewed-on: https://chromium-review.googlesource.com/656862 Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47918}
-
Michael Starzinger authored
This removes logic related to healing of the optimized code slot within the feedback vector from the {FastNewClosure} builtin. The underlying code will by now self-heal making it obsolete during closure creation. It will also simplify future inline allocation of closures. R=jarin@chromium.org BUG=v8:6563 Change-Id: If57fe00e3a98c2af423a833c98a465a669b8f3bc Reviewed-on: https://chromium-review.googlesource.com/649551Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47917}
-
Georg Neis authored
R=petermarshall@chromium.org Bug: Change-Id: I4c14032aa1bd4fad39cf3db36556d53a529a52b3 Reviewed-on: https://chromium-review.googlesource.com/654865Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47916}
-
Daniel Bevenius authored
Bug: Change-Id: I236e6efe4142741ae8dc7e4ca4acdf8a65890c16 Reviewed-on: https://chromium-review.googlesource.com/647534Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47915}
-
Michael Starzinger authored
This removes the ability to create a copy of a code-stub with a given replacement pattern applied. It is in preparation of having the ability to write-protect code objects. R=ishell@chromium.org BUG=v8:6409 Change-Id: Id7528b3bfc53ece73d8c58b0ac96c6e5702a9d45 Reviewed-on: https://chromium-review.googlesource.com/654605Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47914}
-
Benedikt Meurer authored
Add support to the JSCallReducer to recognize JSConstruct nodes where the target is the Object constructor, and reduce them to JSCreate nodes if either (a) no value is passed to the Object constructor, or (b) the target and new.target are definitely not identical, by checking whether both target and new.target are different HeapConstants (if they are not, then the JSCreateLowering will not be able to do a lot with the JSCreate anyways). This should cover the relevant cases for subclassing appropriately. It fixes the 3-4x slowdown on the micro-benchmark mentioned in the linked bug, baseNoExtends: 752 ms. baseExtendsObject: 752 ms. baseExtendsViaFactory: 751 ms. and thus removes the performance cliff. R=jarin@chromium.org Bug: v8:6801 Change-Id: Id265fd1399302a67b5790a6d0156679920c58bdd Reviewed-on: https://chromium-review.googlesource.com/657019Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47913}
-
Michael Hablich authored
This reverts commit 9c0471b3. Reason for revert: blocks roll https://chromium-review.googlesource.com/c/chromium/src/+/656897 Original change's description: > Add V8_ENABLE_CHECKS define to public config > > We should add this define to external_config because it is used in > public include v8.h (e.g.: https://cs.chromium.org/chromium/src/v8/include/v8.h?l=272&rcl=5cd6565d5ad06a8cb5a1d9d502d15a54e4fa5bbe) > > Change-Id: I795a3de448029e34033cf8f83094bdea3590bbb9 > Reviewed-on: https://chromium-review.googlesource.com/654876 > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47901} TBR=gsathya@chromium.org,atimoxin@yandex-team.ru Change-Id: I8265f78a9ab260b719226843afd649245e72434f No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/657157Reviewed-by: Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#47912}
-
Yang Guo authored
R=mstarzinger@chromium.org Change-Id: I6cb9d9b7b82ce05299bb6088b187e91c4fa2ca0f Reviewed-on: https://chromium-review.googlesource.com/649750 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47911}
-
Aseem Garg authored
This is revert of commit aee1e1fb with the fix for A1 and N6 jetstream failure. R=bradnelson@chromium.org,mtrofin@chromium.org,clemensh@chromium.org Bug: chromium:750828 Change-Id: Id38896af51315f76a0667ace32c77a2ba7287eec Reviewed-on: https://chromium-review.googlesource.com/607092 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Brad Nelson <bradnelson@chromium.org> Cr-Commit-Position: refs/heads/master@{#47910}
-
Mircea Trofin authored
The previous design assumed we can't possibly have a cycle involving an instance, however, we can. For example: a script can reference an instance, which ends up referencing the native context because of how we generate wasm-to-js wrappers; that references the global object, which then references the script. A global handle to the indirect function table can then root such a cycle. That means the instance is never collected, which never deletes the global handle. This change addresses that by making the handles weak. Bug: Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ief7263af83974bf96505a4fba65d162474fe7c7c Reviewed-on: https://chromium-review.googlesource.com/653852 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Brad Nelson <bradnelson@chromium.org> Reviewed-by: Aseem Garg <aseemgarg@chromium.org> Cr-Commit-Position: refs/heads/master@{#47909}
-
- 07 Sep, 2017 5 commits
-
-
Jaideep Bajwa authored
Port e67420cb Original Commit Message: There are two main reasons to move DeserializeLazy to ASM: 1. We avoid complications around the distinction between Call/Construct cases by making sure relevant registers (e.g. new_target) remain unclobbered. 2. We can avoid the tail-call through CodeFactory::Call/Construct by jumping directly to the deserialized code object. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:6624 LOG=N Change-Id: Idd9f1fd967d64e952f48e5b35d2d4b49a9c28007 Reviewed-on: https://chromium-review.googlesource.com/656502Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47908}
-
Jaideep Bajwa authored
This issue was exposed with this CL https://chromium-review.googlesource.com/c/v8/v8/+/654257 R=joransiu@ca.ibm.com, jyan@ca.ibm.com BUG= LOG=N Change-Id: I216bfc8079bf62a58f8e6c20d4ac9d22bc445b51 Reviewed-on: https://chromium-review.googlesource.com/656306Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47907}
-
Sathya Gunasekaran authored
This is a reland of a2ed0514 Original change's description: > [debug] Add test for promise finally > > As of v8:6536, we no longer have to mark builtins explicitly. > > Also remove test whitelist for promise finally > builtins. > > Bug: v8:6088, v8:5967 > Change-Id: I7f98dfe7708678653e944ac76ba9938205490b16 > Reviewed-on: https://chromium-review.googlesource.com/654067 > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47896} TBR=jgruber@chromium.org Bug: v8:6088, v8:5967 Change-Id: I25a1820e04596a44769fc8ded80678f3663bbcd5 Reviewed-on: https://chromium-review.googlesource.com/655740Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#47906}
-
Marja Hölttä authored
When the bailout triggered, we assumed we're generating data (i.e., we're inside a non-arrow function). This is not true; it's possible that we're already inside an arrow function and not generating data anyway. BUG=v8:5516,chromium:761980 Change-Id: Iad9c8dde283031630953ef9a46c1e68bc0cee048 Reviewed-on: https://chromium-review.googlesource.com/655081Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47905}
-
Adam Klein authored
Tracking labels for most of these statements made no difference: only try-statements require the special treatment of being wrapped in a block. The previous code existed to support strong mode, which is long gone. This also results in a tiny regression of the error message for a labelled `continue` statement targeting itself, but I'm not convinced that anyone would ever intend to label a continue statement (and Chakra and SpiderMonkey give similarly inaccurate error messages for this case). This is effectively a revert of d8bccfe9. Bug: v8:6092 Change-Id: I25b62e10f6a20597e9686f08df76ba9724249618 Reviewed-on: https://chromium-review.googlesource.com/653380Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47904}
-