- 24 Jun, 2020 1 commit
-
-
Camillo Bruni authored
With this CL d8 exits with an error code if there is an unhandled promise rejection, e.g. due tue a failed assertion in a promise. Up until now these assertions were just ignored. Bug: v8:10556 Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#68503}
-
- 04 Mar, 2019 1 commit
-
-
Ross McIlroy authored
BUG=v8:8801 Change-Id: I9d9d9824c6c9ad0176bbfd3723da1b578b17c256 Reviewed-on: https://chromium-review.googlesource.com/c/1495555 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#60001}
-
- 20 Feb, 2018 1 commit
-
-
Benedikt Meurer authored
This makes the inlining of the default resolve/reject closures generated by the Promise constructor effective. To be really useful we still need to have the Promise constructor inlined (work-in-progress) and eventually track SharedFunctionInfo feedback in the CALL_IC. Bug: v8:2206, v8:7253 Change-Id: I08fa8ca72754f459ae36027a55377ef57d411cdc Reviewed-on: https://chromium-review.googlesource.com/926103 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#51390}
-
- 13 Feb, 2018 1 commit
-
-
Benedikt Meurer authored
This introduces dedicated builtins - FulfillPromise, - RejectPromise, and - ResolvePromise, which perform the corresponding operations from the language specification, and removes the redundant entry points and the excessive inlining of these operations into other builtins. We also add the same logic on the C++ side, so that we don't need to go into JavaScript land when resolving/rejecting from the API. The C++ side has a complete implementation, including full support for the debugger and the current PromiseHook machinery. This is to avoid constantly crossing the boundary for those cases, and to also simplify the CSA side (and soon the TurboFan side), where we only do the fast-path and bail out to the runtime for the general handling. On top of this we introduce %_RejectPromise and %_ResolvePromise, which are entry points used by the bytecode and parser desugarings for async functions, and also used by the V8 Extras API. Thanks to this we can uniformly optimize these in TurboFan, where we have corresponding operators JSRejectPromise and JSResolvePromise, which currently just call into the builtins, but middle-term can be further optimized, i.e. to skip the "then" lookup for JSResolvePromise when we know something about the resolution. In TurboFan we can also already inline the default PromiseCapability [[Reject]] and [[Resolve]] functions, although this is not as effective as it can be right now, until we have inlining support for the Promise constructor (being worked on by petermarshall@ right now) and/or SFI based CALL_IC feedback. Overall this change is meant as a refactoring without significant performance impact anywhere; it seems to improve performance of simple async functions a bit, but otherwise is neutral. Bug: v8:7253 Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51260}
-