- 14 Feb, 2019 1 commit
-
-
Benedikt Meurer authored
When calling into API callbacks from TurboFan optimized, we can currently only take a fast-path when TurboFan is able to find some information about the receiver in the graph, or when the API callback specifies that it neither requires an access check (aka "accepts any receiver") nor an interface check (aka "compatible receiver check"). This change introduces a new CallFunctionTemplate builtin that sits in front of the CallApiCallback builtin and does both the access as well as the interface check as necessary (and raises appropriate exceptions). This way TurboFan can still call into the API callback via the fast-path even without ahead knowledge about the receiver, which is significantly faster than the generic call machinery for API callbacks. On the test case from the Angular team[1], the interesting metrics improve from DOM_mono: 0.273 ms DOM_mega: 0.571 ms DOM_call: 0.649 ms to DOM_mono: 0.264 ms DOM_mega: 0.572 ms DOM_call: 0.368 ms so the DOM_call is only about **1.4 times slower** than the DOM_mono and about **1.5 times faster** than the DOM_mega case (compared to **2.4 times slower**). Execution time in the DOM_call was reduced by around **~45%**. Currently this new code path is limited to TurboFan optimized code, but the idea is to eventually migrate the API calls from baseline to also use the new CSA functionality, but there are lot's of subleties to take into account, so starting with small changes to get coverage for the basic building blocks. [1]: https://mhevery.github.io/perf-tests/DOM-megamorphic.html Bug: v8:8820 Change-Id: Ie1029cf182ce05a6e519fd9a9d4fa825db8adb4c Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/1470129 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59598}
-
- 01 Jun, 2018 1 commit
-
-
Camillo Bruni authored
Drive-by-fix: - Add CSA::LoadElementsKind helper Bug: v8:7796 Change-Id: Icbf81effdd42efa7f8ec56f8d1a40c331c7a25e4 Reviewed-on: https://chromium-review.googlesource.com/1078849 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#53472}
-
- 20 Jun, 2017 1 commit
-
-
Peter Marshall authored
We can remove a lot of native code and rely on CallOrConstructVarargs to do the stack manipulation for us. This will also take advantage of the fast-path for double arrays in CallOrConstructDoubleVarargs. We can also remove Runtime_SpreadIterableFixed because it isn't used anymore. We just call directly into spread_iterable from CSA. Bug: v8:6488, chromium:704966 Change-Id: I81a18281f062619851134fff7ce88471566ee3b5 Reviewed-on: https://chromium-review.googlesource.com/535615Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#46038}
-
- 08 Jun, 2017 1 commit
-
-
bmeurer authored
This splits the monolithic Apply builtin into several smaller builtins, namely CallVargargs and ConstructVarargs, which accept a length and a FixedArray of elements and deal with the actual stack manipulation, and CallWithArrayLike / ConstructWithArrayLike that deal with getting the elements from the receiver (for Function.prototype.apply, Reflect.apply and Reflect.construct), which can now be written using the CSA. The idea is that these builtins can be reused by TurboFan directly in the future when we optimize apply better, and that we can also reuse the core logic in the handling of spread calls/constructs. R=petermarshall@chromium.org BUG=v8:4587,v8:5269 Review-Url: https://codereview.chromium.org/2930623002 Cr-Commit-Position: refs/heads/master@{#45794}
-