- 07 Sep, 2017 31 commits
-
-
Michael Starzinger authored
R=marja@chromium.org Change-Id: I7e1b471c425a28d77100ce3cda34511393b31365 Reviewed-on: https://chromium-review.googlesource.com/654901Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47892}
-
jgruber authored
TBR=yangguo@chromium.org,verwaest@chromium.org Bug: v8:6624,v8:6787 Change-Id: I6fbad17cb2e9d6238b84fc96a518e545a7156769 Reviewed-on: https://chromium-review.googlesource.com/655168 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47891}
-
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}
-
Clemens Hammacher authored
Use operator== and operator!= instead. Implemented for x64, ia32, arm, arm64, mips and mips64. R=mstarzinger@chromium.org,ishell@chromium.org,jgruber@chromium.org Change-Id: Iad0f03f7f442709dcaa12d6a49a8bc4b03b9cdae Reviewed-on: https://chromium-review.googlesource.com/654857 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47889}
-
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}
-
jgruber authored
Lazy deserialization requires a fully set-up isolate (in particular, we need Isolate::snapshot_blob). This CL disables lazy deserialization in affected tests. This should be fixed at some point by setting up the isolate as needed. Bug: v8:6624 Change-Id: I94f792d9dcc8a3ba2d91fdeadd9e04ebb0bb50cf Reviewed-on: https://chromium-review.googlesource.com/655162Reviewed-by:
-
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}
-
jgruber authored
When setting up an isolate for serialization, we need to disable lazy deserialization to avoid replacing lazy builtins with DeserializeLazy. Bug: v8:6624 Change-Id: I3e10e262f6dd856f92fd83e5e475127e8ca3f3bf Reviewed-on: https://chromium-review.googlesource.com/655161Reviewed-by:
-
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:
-
jgruber authored
debug::GetBuiltin creates a new JSFunction and constructs a new SFI at runtime. Ensure that this SFI has the correct builtin_id set. Bug: v8:6624,v8:6788 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I25da2ad5e69478f81042d3e3bf7e7e2644e7050d Reviewed-on: https://chromium-review.googlesource.com/654643Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If0b4aed4e5770702b36e3e1a34189a1b18a9cf17 Reviewed-on: https://chromium-review.googlesource.com/631837Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47882}
-
jgruber authored
The optimizer produces direct calls to these builtins. Lazy deserialization depends on the existance of a shared function info, so these need to be blacklisted for now. Bug: v8:6624,v8:6786 Change-Id: I69e766d327338d333a9a8e6ba9a394aad5f06f01 Reviewed-on: https://chromium-review.googlesource.com/655160Reviewed-by:
-
Michael Starzinger authored
This finally allows to include the factory.h header without having to also inlcude the object-inl.h inline header. It will in turn enable the removal of the last inline header inclusion violation. R=marja@chromium.org Change-Id: Ice2821e1f74cf428d80c8ebf606a218026f37677 Reviewed-on: https://chromium-review.googlesource.com/654862Reviewed-by:
-
jgruber authored
kNextChunk handling in deserializer.cc relies on the reservation mechanism, which is not used by builtin deserialization. To avoid complications, we work around this for now by skipping over these bytecodes. This will soon become unnecessary once allocations & reservations have been refactored. Bug: v8:6624 Change-Id: I9e861268ee2b3f49fe7f3ed6c1e3501b4b47dc37 Reviewed-on: https://chromium-review.googlesource.com/655158Reviewed-by:
-
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:
-
Marja Hölttä authored
What happened: - When rewriting in DoParseFunction, the relevant function scope is no longer in the scope stack. - The correct scope is given to the PatternRewriter. - PatternRewriter called to Parser::BuildIteratorCloseForCompletion. - BuildIteratorCloseForCompletion would just call NewTemporary (which creates a new temporary in Parser's current scope) instead of using the scope passed to it and calling NewTemporary on it. - Normally this went unnoticed, since it doesn't matter that much where the temporary is. - But in the lazy arrow func case, the Parser's scope at that point was the already-resolved outer scope, and a DCHECK detected this problem. Kudos & thanks to verwaest@ for a debugging session :) BUG=chromium:761831 Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809 Reviewed-on: https://chromium-review.googlesource.com/650297 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47877}
-
jgruber authored
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. Bug: v8:6624 Change-Id: Idef8fa73d804e16d510f62766c735d1891729b81 Reviewed-on: https://chromium-review.googlesource.com/652472Reviewed-by:
-
Juliana Franco authored
Given that we no longer need to iterate over lists of optimized JS functions (c.f. https://chromium-review.googlesource.com/c/v8/v8/+/647596), we can remove this field. Thus saving the size of one pointer per function. Bug: v8:6637 Change-Id: If77951f2eddba33ba350fa9ddf03a4edb3f7c7d8 Reviewed-on: https://chromium-review.googlesource.com/652373Reviewed-by:
-
Andreas Haas authored
The wasm-async fuzzer uses the bytes provided by the fuzzer engine directly as wasm module bytes, compiles them with async compilation, and then tries to execute the "main" function of the module. This "main" can have an infinite loop which causes a timeout in the fuzzer. With this CL the "main" function is first executed with the interpreter. If the execution in the interpreter finishes within 16k steps, which means that there is no infinite loop, also the compiled code is executed. I added the raw fuzzer input as a test case because in this case I really want to test the fuzzer and not V8. R=clemensh@chromium.org Bug: chromium:761784 Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162 Reviewed-on: https://chromium-review.googlesource.com/651046 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=rmcilroy@chromium.org BUG=v8:6409 Change-Id: Ib8bb85674f63fed47aa55a775eaade6b14d60f2e Reviewed-on: https://chromium-review.googlesource.com/654040Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47873}
-
Camillo Bruni authored
Change-Id: If7db250e242350f83b368b33b60399afd5312b36 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/654658Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47872}
-
Camillo Bruni authored
The help output prints the first line of the doc string. Change-Id: I76817d5138b7bb7ba8034c6a5d803b5aaf1201f7 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/654603Reviewed-by:
-
Ross McIlroy authored
JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
-
Benedikt Meurer authored
Introduce NodeProperties::NoObservableSideEffectBetween to check if there's any observable side effect between two nodes in the effect chain. Use this to guard the insertion of potentially redundant map checks in the lowering of Object.prototype.hasOwnProperty and keyed accesses within a for..in loop. This gives another boost on the for..in performance front. Bug: v8:6702 Change-Id: I68133f14ad388a1a7422714319c9b323d5cf8bc4 Reviewed-on: https://chromium-review.googlesource.com/654640Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#47869}
-
Franziska Hinkelmann authored
Bug: Change-Id: I3a97b303bcb4cbb4835fb5de8c55a21eaaa93504 Reviewed-on: https://chromium-review.googlesource.com/649615Reviewed-by:
-
jgruber authored
The lazy deserialization builtin id is usually set when the shared function info is created in Factory::NewSharedFunctionInfo, which looks at the given code object to grab the builtin id. However, this doesn't work when the shared function info is created after deserialization, as is the case for harmony features that can be toggled with runtime flags. At this point, lazy builtins have already been replaced by DeserializeLazy in the builtins table. To ensure that the lazy deserialization id is correct in this case, explicitly set it in bootstrapper functions. Bug: v8:6624, v8:6788 Change-Id: Ia6ac3a4842d2659d5de6d92f378ea221b5508040 Reviewed-on: https://chromium-review.googlesource.com/652477 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Mostyn Bramley-Moore authored
Followup after https://chromium-review.googlesource.com/c/v8/v8/+/652427 which triggered FORWARD_DECLARE macro redefinition warnings/errors. Let's make sure to undef this macro at the end of source files that create it. Bug: chromium:746958 Change-Id: Ie70743c836db45eb51f412a0d6359f0f667319d3 Reviewed-on: https://chromium-review.googlesource.com/654657 Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Reviewed-by:
-
jgruber authored
This extends the list by two cases that we currently cannot handle: FunctionPrototypeHasInstance is called directly without going through Call (https://crbug.com/v8/6786). The Proxy constructor uses a custom construct stub (https://crbug.com/v8/6787). Bug: v8:6624,v8:6786,v8:6787 Change-Id: I21b883bf94bfa170d1da7aa812d09f813d881133 Reviewed-on: https://chromium-review.googlesource.com/651424Reviewed-by:
-
Yang Guo authored
This came up in the context of a Twitter discussion, see this particular tweet https://twitter.com/hashseed/status/905684048382754817 and the relevant thread. Change-Id: If2447169df999b64ce701a44321d48ba1bff2a06 Reviewed-on: https://chromium-review.googlesource.com/654598Reviewed-by:
-
Yang Guo authored
This reduces the arm32 binary by around 20kB. R=jkummerow@chromium.org, mstarzinger@chromium.org Bug: v8:6055 Change-Id: If9098e49793b29dceb8292aff6f668ca28a07728 Reviewed-on: https://chromium-review.googlesource.com/652427Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Yuki Shiino authored
As Blink needs a way to define a property without running a script, make Object::DefineOwnProperty use ENTER_V8_NO_SCRIPT if the receiver object is not a JSProxy. Quite similar to https://crrev.com/c/v8/v8/+/608348 Bug: chromium:728583, chromedriver:1978, chromium:762385 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: If358bf0d156139c456de369ac04da2be6e626143 Reviewed-on: https://chromium-review.googlesource.com/651949 Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47862}
-
- 06 Sep, 2017 9 commits
-
-
Jeremy Roman authored
This reduces the number of times this string is copied from two to one. Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I8680cfc1ef1d6c2cfd3bc4970fe698bb904ce328 Reviewed-on: https://chromium-review.googlesource.com/652591Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Jeremy Roman <jbroman@chromium.org> Cr-Commit-Position: refs/heads/master@{#47861}
-
Jaideep Bajwa authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com BUG= LOG=N Change-Id: I353f953b6b2d9c20ebd9d141b33da47761f3e43b Reviewed-on: https://chromium-review.googlesource.com/653808Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47860}
-
Mostyn Bramley-Moore authored
This macro is defined all over the place, and often causes macro redefinition errors in jumbo builds. Let's make sure all such instances created in source files are #undef'ed. Candidate files found with: grep -wL '#undef TRACE' $(git grep -wl '#define TRACE' -- '*.cc') While we're at it, let's undef all macros defined in these files. Bug: chromium:746958 Change-Id: I639ca2b141f908457d1b2601cd6d5827dee0ead0 Reviewed-on: https://chromium-review.googlesource.com/652476Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Reviewed-by:
-
Anisha Rohra authored
Port 30f08f39 Always return to the InterpreterEntryTrampoline rather than calling the InterpreterExitTrampoline from the Return bytecode handler. This fixes a regression which occured if we upset the call/return stack by skipping the return to the InterpreterEntryTrampoline from the return bytecode handler. R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Id2bae444e72cd7ddfb74f4861fc2c4f7b5e9bda5 Reviewed-on: https://chromium-review.googlesource.com/653618Reviewed-by:
Jaideep Bajwa <bjaideep@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47858}
-
Sathya Gunasekaran authored
R=adamk@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ie59cc231e130fad391508e5c47e01d32d0a78806 Reviewed-on: https://chromium-review.googlesource.com/651357Reviewed-by:
-
Mythri authored
This is the second attempt at removing this. Earlier (https://chromium-review.googlesource.com/579194) there were regressions on some of the functions related to maps and sets. Now that all of them are ported to CSA, we can remove the remaining uses of SetForceInlineFlag. Bug: v8:6682 Change-Id: Iebf296038aa24b65181b0d10531b0569d313e7fc Reviewed-on: https://chromium-review.googlesource.com/647452Reviewed-by:
-
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 authored
Bug: v8:6333 Change-Id: Ic1956d3dcfc0309fe2b65344e5af7235d5b804a2 Reviewed-on: https://chromium-review.googlesource.com/651413Reviewed-by:
-
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:
-
