- 29 Sep, 2017 2 commits
-
-
Yang Guo authored
Change the default to false. Block coverage will need to be enabled explicitly via inspector protocol, which is already being done. R=franzih@chromium.org Bug: v8:6738 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I08684ce7b501981bc376a6bc6181fabac9628a63 Reviewed-on: https://chromium-review.googlesource.com/689234Reviewed-by:
Franziska Hinkelmann <franzih@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48235}
-
Yang Guo authored
And some refactoring to the existing code for LiveEdit. R=jarin@chromium.org Change-Id: Ic1d626db9722b39cbcd83bf6878fc24d6094e612 Reviewed-on: https://chromium-review.googlesource.com/687014 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48233}
-
- 28 Sep, 2017 1 commit
-
-
Ben L. Titzer authored
Note that this also makes it possible to move several classes into the module-compiler.cc file and inline their implementations. This also allows removing several uses of wasm-module.h from other places in V8 that include wasm-objects.h. R=yangguo@chromium.org,clemensh@chromium.org,ahaas@chromium.org Bug: Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I303ee2bb49dc53c951d377a1b65699c1e0e91da7 Reviewed-on: https://chromium-review.googlesource.com/687494Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48204}
-
- 25 Sep, 2017 2 commits
-
-
Clemens Hammacher authored
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an embedded comparison. This gives better error messages and also does the right comparison for signed/unsigned mismatches. This will allow us to reenable the readability/check cpplint check. R=yangguo@chromium.org Bug: v8:6837 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I88e5afea1ad0fdf23a81b380e64ff356bbc20112 Reviewed-on: https://chromium-review.googlesource.com/681374Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48138}
-
Maya Lekova authored
Bug: Change-Id: I7cb8ace4183c0dcf34d71d1b378204383c17ba56 Reviewed-on: https://chromium-review.googlesource.com/678718Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Maya Lekova <mslekova@google.com> Cr-Commit-Position: refs/heads/master@{#48133}
-
- 17 Sep, 2017 1 commit
-
-
Daniel Bevenius authored
I noticed that ScopeIterator::CurrentContext returns an empty Handle whereas functions like ScopeIterator::CurrentScopeInfo call Handle<Context>::null() instead. This commit suggests changing this for consistency. Bug: Change-Id: I8735d655a8c0affeb6a18e74efe0d33bf6d5e899 Reviewed-on: https://chromium-review.googlesource.com/668440Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48057}
-
- 16 Sep, 2017 1 commit
-
-
peterwmwong authored
- Added TFJ builtins for S.p.{anchor, big, blink, bold, fontcolor, fontsize, fixed, italics, link, small, strike, sub, sup} - Removed functionality from string.js Bug: v8:5049 Change-Id: I3a91b52eaceef5c47bb55ed62780d72ef1e802e9 Reviewed-on: https://chromium-review.googlesource.com/666487 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48056}
-
- 15 Sep, 2017 2 commits
-
-
Jakob Gruber authored
It's quite possible for DebugInfos to exist without the presence of a bytecode array, since DebugInfos are created for all functions for which we have a CoverageInfo. Free such objects properly. Also move the corresponding deletion of CoverageInfos on unload up before the early exit. Bug: v8:6000 Change-Id: Idde45b222290aa8b6828b61ff2251918b8ed2aed Reviewed-on: https://chromium-review.googlesource.com/664811Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48024}
-
peterwmwong authored
- Removes S.p.repeat from string.js - Adds StringPrototypeRepeat TFJ Bug: v8:5049 Change-Id: I0b2d512bffd97dfc2c3ba6783e2e41c4db6c8faa Reviewed-on: https://chromium-review.googlesource.com/659097 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#48023}
-
- 14 Sep, 2017 3 commits
-
-
Sigurdur Asgeirsson authored
Bug: chromium:763010 Change-Id: Iafed5a0e8087f415cd2c11a0b1326c04bd01ef80 Reviewed-on: https://chromium-review.googlesource.com/665351Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48018}
-
Franziska Hinkelmann authored
If TypeProfile goes out of scope, ScriptData and Entry still rely on TypeProfiles's type_profile_. Make type_profile_ a shared_ptr owned by all three classes to prevent use after free. Bug: v8:5933 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ida7d66dadc17a816cf4439a25e6f714edccffa2c Reviewed-on: https://chromium-review.googlesource.com/659937Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#48013}
-
Franziska Hinkelmann authored
Bug: Change-Id: I597b2c1067e309c2545daef4223b3b883d15a6c1 Reviewed-on: https://chromium-review.googlesource.com/657761Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#48011}
-
- 13 Sep, 2017 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I3df5d50f81909188ee0cb31d0f479aadeeabe20f Reviewed-on: https://chromium-review.googlesource.com/662780Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47991}
-
- 12 Sep, 2017 2 commits
-
-
Alexey Kozyatinskiy authored
Some API functions have no context and debug::ScopeIterator:: CreateForFunction is crashing on attempt to get context. R=jgruber@chromium.org Bug: chromium:759913 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0a9861ea2d19bceff97c4394b34a8dda45222b78 Reviewed-on: https://chromium-review.googlesource.com/661789 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47981}
-
Adam Klein authored
This continues to move the "desugaring" of unary operators further down the pipeline, in this case into the bytecode handlers for new bytecodes `Negate` and `BitwiseNot` and the corresponding TF code in BytecodeGraphBuilder. Bug: v8:6971 Tbr: yangguo@chromium.org Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb Reviewed-on: https://chromium-review.googlesource.com/661146 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47980}
-
- 11 Sep, 2017 6 commits
-
-
Georg Neis authored
BigInt is a new primitive type of arbitrary precision integers, proposed in https://tc39.github.io/proposal-bigint. This CL introduces a corresponding instance type, map, and C++ class to V8 and adds BigInt support to a few operations (see the test file). Much more is to come. Also, the concrete representation of BigInts is not yet fixed, currently a BigInt is simply a wrapped Smi. Bug: v8:6791 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45 Reviewed-on: https://chromium-review.googlesource.com/657022Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47956}
-
Mike Stanton authored
Since we don't have a full-codegen compiler anymore, we no longer generate Code::FUNCTION kind. Nice! Here is some cleanup. Bug: v8:6409 Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762 Reviewed-on: https://chromium-review.googlesource.com/657817 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47951}
-
Toon Verwaest authored
Bug: v8:5269 Change-Id: Ie649a83435f74b6dd705991c264085f28b12736c Reviewed-on: https://chromium-review.googlesource.com/655438 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47948}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If0554f01068fb76228e85cfe120630eda86de41d Reviewed-on: https://chromium-review.googlesource.com/659997Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47945}
-
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}
-
- 08 Sep, 2017 2 commits
-
-
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}
-
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}
-
- 07 Sep, 2017 5 commits
-
-
Peter Marshall authored
Bug: v8:6333 Change-Id: Ibc704172ebc796977b8d8cfae6976666d186f12c Reviewed-on: https://chromium-review.googlesource.com/652450 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47890}
-
Toon Verwaest authored
This speeds up the baseline performance of Object by 20%. With this change, the callViaObject when run with --noopt goes from 10718ms to 8577ms on the benchmark from: http://benediktmeurer.de/2017/08/31/object-constructor-calls-in-webpack-bundles Bug: v8:6772 Change-Id: Id0e54ba44204a1700885185ec360e1c56834fb73 Reviewed-on: https://chromium-review.googlesource.com/654900Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#47888}
-
Yang Guo authored
R=caseq@chromium.org Change-Id: Ie7d8e2eb1452758895f47c749cd7f1ea9b565301 Reviewed-on: https://chromium-review.googlesource.com/654038Reviewed-by:
Franziska Hinkelmann <franzih@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#47886}
-
Peter Marshall authored
This is a reland of 9b35364c Original change's description: > [cleanup] Replace more instances of List with std::vector. > > Bug: v8:6333 > Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2 > Reviewed-on: https://chromium-review.googlesource.com/651413 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47854} Bug: v8:6333 Change-Id: I5d9482b061f26b57550a421ea4099372dc80767f Reviewed-on: https://chromium-review.googlesource.com/654898Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#47884}
-
jgruber authored
With lazy deserialization, the target code object may have been replaced by DeserializeLazy. In that case, we can get the target builtin id from the shared function info, and we need to skip RelocInfo iteration (it doesn't exist yet). Bug: v8:6624 Change-Id: I765b74de313e65bfdf0122f13535029994fc0de1 Reviewed-on: https://chromium-review.googlesource.com/655159Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47878}
-
- 06 Sep, 2017 3 commits
-
-
Peter Marshall authored
This reverts commit 9b35364c. Reason for revert: Failing tests on Win64 Debug Original change's description: > [cleanup] Replace more instances of List with std::vector. > > Bug: v8:6333 > Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2 > Reviewed-on: https://chromium-review.googlesource.com/651413 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47854} TBR=neis@chromium.org,jgruber@chromium.org,petermarshall@chromium.org Change-Id: Ifa2cd98edd9ec5e1d67c81501f0d9e8aae69536c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6333 Reviewed-on: https://chromium-review.googlesource.com/653117Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#47855}
-
Peter Marshall authored
Bug: v8:6333 Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2 Reviewed-on: https://chromium-review.googlesource.com/651413Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#47854}
-
peterwmwong authored
- Convert S.p.{trim, trimLeft, trimRight} to TFJ - Fast paths for one/two byte strings - Added StringTrimAssembler - Added helper kStringTrim runtime to handle slow paths Quick measurements show >2.7x improvement: https://github.com/peterwmwong/v8-perf/tree/master/string-trim Bug: v8:6680 Change-Id: I79929129aa3d5dea20f094d648afe46adbf61a49 Reviewed-on: https://chromium-review.googlesource.com/647647Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47853}
-
- 05 Sep, 2017 1 commit
-
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24 TBR: mstarzinger@chromium.org Reviewed-on: https://chromium-review.googlesource.com/647596 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47808}
-
- 04 Sep, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit 84c2dfce. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876 Original change's description: > Remove weak-list of optimized JS functions. > > This CL removes the weak-list of JS functions from the context > and all the code that iterares over it. This list was being used > mainly during deoptimization (for code unlinking) and during > garbage collection. Removing it will improve performance of > programs that create many closures and trigger many scavenge GC > cycles. > > No extra work is required during garbage collection. However, > given that we no longer unlink code from JS functions during > deoptimization, we leave it as it is, and on its next activation > we check whether the mark_for_deoptimization bit of that code is > set, and if it is, than we unlink it and jump to lazy compiled > code. This check happens in the prologue of every code object. > > We needed to change/remove the cctests that used to check > something on this list. > > Working in x64, ia32, arm64, arm, mips64 and mips. > > Bug: v8:6637 > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 > Reviewed-on: https://chromium-review.googlesource.com/600427 > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47790} TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6637 Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47792}
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 Reviewed-on: https://chromium-review.googlesource.com/600427 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47790}
-
- 01 Sep, 2017 2 commits
-
-
Benedikt Meurer authored
This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
-
Michael Starzinger authored
This adds support for lowering {JSCreateArguments} within outermost frames of type {CreateArgumentsType::kMappedArguments}. It will hence enable escape analysis to work with such objects and allow for further optimization. This also adds a new {NewMappedArgumentsElements} simplfied operator. Note that escape analysis support for this new operator will be done as a follow-up. R=tebbi@chromium.org Change-Id: I0e2fac25c654f796433f57b116964053b6b68635 Reviewed-on: https://chromium-review.googlesource.com/641454 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#47761}
-
- 31 Aug, 2017 1 commit
-
-
Michael Lippautz authored
heap-inl.h exposes the whole world, which is fine from other inline files but not from regular headers. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I09ec67c6558682cb0d5181031bc39341a3f4c5bf Reviewed-on: https://chromium-review.googlesource.com/643294Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47729}
-
- 29 Aug, 2017 1 commit
-
-
Peter Marshall authored
Bug: v8:6333 Change-Id: I6292bc6b31c696dddd3e3361a519e7275404b144 Reviewed-on: https://chromium-review.googlesource.com/631879Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#47663}
-
- 28 Aug, 2017 2 commits
-
-
Jakob Gruber authored
This reverts commit f6d73509. Reason for revert: Perf regressions https://crbug.com/758126 Original change's description: > [csa] Refactor large-object handling in string allocation > > CSA::AllocateSeq{One,Two}ByteString used its own home-grown handling to > allocate very large strings. This CL refactors both methods to use > AllocationFlags::kAllowLargeObjectAllocation instead. Callers now need > to specify explicitly if large-object allocation is possible or not. > > Bug: chromium:636391 > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: I0b7ffb0b083f4e977cea42c500f8f2ee1c60519f > Reviewed-on: https://chromium-review.googlesource.com/625738 > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47504} TBR=cbruni@chromium.org,jgruber@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:636391 Change-Id: Iab88ce400f489a677df821d4053bd3678289ae2e Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/637392Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47639}
-
Benedikt Meurer authored
Optimize the common pattern for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { // do something } } which is part of the guard-for-in style in ESLint (see the documentation at https://eslint.org/docs/rules/guard-for-in for details). This pattern also shows up in React and Ember applications quite a lot (and is tested by the appropriate Speedometer benchmarks, although not dominating those benchmarks, since they spent a lot of time in non-TurboFan'ed code). This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro- benchmarks in v8:6702, which look like this function forInHasOwnProperty(o) { var result = 0; for (var i in o) { if (o.hasOwnProperty(i)) { result += 1; } } return result; } function forInHasOwnPropertySafe(o) { var result = 0; for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { result += 1; } } return result; } by around 4x and allows for additional optimizations in the future, by also elimiating the megamorphic load when accessing the enumerated properties. This changes the interpreter ForInNext bytecode to collect more precise feedback about the for-in state, which now consists of three individual states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state means that the ForInNext has only seen objects with a usable enum cache thus far, whereas GENERIC means that we have seen some slow-mode for..in objects as well. R=jarin@chromium.org Bug: v8:6702 Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604 Reviewed-on: https://chromium-review.googlesource.com/636964 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47632}
-