-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deps: cherry-pick Swallowed Rejection Hook from V8 #21838
Conversation
This comment has been minimized.
This comment has been minimized.
I could cherry-pick the commits without a conflict but got a compilation error:
|
Compilation fixed. Repro:
|
kPromiseHandlerAddedAfterReject = 1 | ||
kPromiseHandlerAddedAfterReject = 1, | ||
kPromiseRejectAfterResolved = 2, | ||
kPromiseResolveAfterResolved = 3, |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Line 72 in 210fea5
|
@targos just a few days ago in the @nodejs/promises-debugging group we discussed this together and I asked @MayaLekova if she could backport that upstream. Should we maybe wait for that? :-) In general I am happy to have it in Node and I have no strong opinion but I thought it is best to have it upstream. |
@BridgeAR we cannot backport on the V8 side since it requires changes in Chrome, which goes against our policy. You'll need to float this as patch on top of Node instead. |
@nodejs/promises-debugging would someone of you like to take it from here and make the necessary changes on Node's side? I'd also be happy to do it myself if you give me directions. I just haven't followed the original discussions and don't how you planned to use this hook. |
@targos I'd suggest to go with v8@d11dafa initially and then with a later PR add actual functionality. |
This is done in preparation for landing https://chromium-review.googlesource.com/c/v8/v8/+/1126099 on the V8 side, which extends the existing PromiseRejectEvent mechanism with new hooks for reject/resolve after a Promise was previously resolved already. Refs: nodejs/promises-debugging#8 Design: https://goo.gl/2stLUY
Original commit message: [turbofan] Remove optimization of default Promise capability functions. The JSCallReducer could in theory inline the default resolve and reject functions passed to the executor in the Promise constructor. But that inlining is almost never triggered because we don't have SFI based feedback in the CallIC. Also the use of the Promise constructor is discouraged, so we shouldn't really need to squeeze the last bit of performance out of this even in the future. Getting rid of this optimization will make significantly easier to implement the Swallowed Rejection Hook, as there's less churn on the TurboFan side then. Bug: v8:7919 Change-Id: If0c54f1c6c7ce95686cd74232be6b8693ac688c9 Reviewed-on: https://chromium-review.googlesource.com/1125926 Commit-Queue: Benedikt Meurer <[email protected]> Reviewed-by: Jaroslav Sevcik <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54210} Refs: v8/v8@2075910
Original commit message: [promise] Implement Swallowed Rejection Hook. This extends the current Promise Rejection Hook with two new events kPromiseRejectAfterResolved kPromiseResolveAfterResolved which are used to detect (and signal) misuse of the Promise constructor. Specifically the common bug like new Promise((res, rej) => { res(1); throw new Error("something") }); where the error is silently swallowed by the Promise constructor without the user ever noticing can be caught via this hook. Doc: https://goo.gl/2stLUY Bug: v8:7919 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I890a7e766cdd1be88db94844fb744f72823dba33 Reviewed-on: https://chromium-review.googlesource.com/1126099 Reviewed-by: Maya Lekova <[email protected]> Reviewed-by: Benedikt Meurer <[email protected]> Reviewed-by: Yang Guo <[email protected]> Commit-Queue: Benedikt Meurer <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54309} Refs: v8/v8@907d7bc
@bmeurer I included your commit. This is ready for review |
This is done in preparation for landing https://chromium-review.googlesource.com/c/v8/v8/+/1126099 on the V8 side, which extends the existing PromiseRejectEvent mechanism with new hooks for reject/resolve after a Promise was previously resolved already. Refs: nodejs/promises-debugging#8 Design: https://goo.gl/2stLUY PR-URL: #21838 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [turbofan] Remove optimization of default Promise capability functions. The JSCallReducer could in theory inline the default resolve and reject functions passed to the executor in the Promise constructor. But that inlining is almost never triggered because we don't have SFI based feedback in the CallIC. Also the use of the Promise constructor is discouraged, so we shouldn't really need to squeeze the last bit of performance out of this even in the future. Getting rid of this optimization will make significantly easier to implement the Swallowed Rejection Hook, as there's less churn on the TurboFan side then. Bug: v8:7919 Change-Id: If0c54f1c6c7ce95686cd74232be6b8693ac688c9 Reviewed-on: https://chromium-review.googlesource.com/1125926 Commit-Queue: Benedikt Meurer <[email protected]> Reviewed-by: Jaroslav Sevcik <[email protected]> Cr-Commit-Position: refs/heads/master@{#54210} Refs: v8/v8@2075910 PR-URL: #21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [promise] Implement Swallowed Rejection Hook. This extends the current Promise Rejection Hook with two new events kPromiseRejectAfterResolved kPromiseResolveAfterResolved which are used to detect (and signal) misuse of the Promise constructor. Specifically the common bug like new Promise((res, rej) => { res(1); throw new Error("something") }); where the error is silently swallowed by the Promise constructor without the user ever noticing can be caught via this hook. Doc: https://goo.gl/2stLUY Bug: v8:7919 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I890a7e766cdd1be88db94844fb744f72823dba33 Reviewed-on: https://chromium-review.googlesource.com/1126099 Reviewed-by: Maya Lekova <[email protected]> Reviewed-by: Benedikt Meurer <[email protected]> Reviewed-by: Yang Guo <[email protected]> Commit-Queue: Benedikt Meurer <[email protected]> Cr-Commit-Position: refs/heads/master@{#54309} Refs: v8/v8@907d7bc PR-URL: #21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [turbofan] Remove optimization of default Promise capability functions. The JSCallReducer could in theory inline the default resolve and reject functions passed to the executor in the Promise constructor. But that inlining is almost never triggered because we don't have SFI based feedback in the CallIC. Also the use of the Promise constructor is discouraged, so we shouldn't really need to squeeze the last bit of performance out of this even in the future. Getting rid of this optimization will make significantly easier to implement the Swallowed Rejection Hook, as there's less churn on the TurboFan side then. Bug: v8:7919 Change-Id: If0c54f1c6c7ce95686cd74232be6b8693ac688c9 Reviewed-on: https://chromium-review.googlesource.com/1125926 Commit-Queue: Benedikt Meurer <[email protected]> Reviewed-by: Jaroslav Sevcik <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54210} Refs: v8/v8@2075910 PR-URL: nodejs#21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [promise] Implement Swallowed Rejection Hook. This extends the current Promise Rejection Hook with two new events kPromiseRejectAfterResolved kPromiseResolveAfterResolved which are used to detect (and signal) misuse of the Promise constructor. Specifically the common bug like new Promise((res, rej) => { res(1); throw new Error("something") }); where the error is silently swallowed by the Promise constructor without the user ever noticing can be caught via this hook. Doc: https://goo.gl/2stLUY Bug: v8:7919 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I890a7e766cdd1be88db94844fb744f72823dba33 Reviewed-on: https://chromium-review.googlesource.com/1126099 Reviewed-by: Maya Lekova <[email protected]> Reviewed-by: Benedikt Meurer <[email protected]> Reviewed-by: Yang Guo <[email protected]> Commit-Queue: Benedikt Meurer <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54309} Refs: v8/v8@907d7bc PR-URL: nodejs#21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [turbofan] Remove optimization of default Promise capability functions. The JSCallReducer could in theory inline the default resolve and reject functions passed to the executor in the Promise constructor. But that inlining is almost never triggered because we don't have SFI based feedback in the CallIC. Also the use of the Promise constructor is discouraged, so we shouldn't really need to squeeze the last bit of performance out of this even in the future. Getting rid of this optimization will make significantly easier to implement the Swallowed Rejection Hook, as there's less churn on the TurboFan side then. Bug: v8:7919 Change-Id: If0c54f1c6c7ce95686cd74232be6b8693ac688c9 Reviewed-on: https://chromium-review.googlesource.com/1125926 Commit-Queue: Benedikt Meurer <[email protected]> Reviewed-by: Jaroslav Sevcik <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54210} Refs: v8/v8@2075910 PR-URL: nodejs#21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [promise] Implement Swallowed Rejection Hook. This extends the current Promise Rejection Hook with two new events kPromiseRejectAfterResolved kPromiseResolveAfterResolved which are used to detect (and signal) misuse of the Promise constructor. Specifically the common bug like new Promise((res, rej) => { res(1); throw new Error("something") }); where the error is silently swallowed by the Promise constructor without the user ever noticing can be caught via this hook. Doc: https://goo.gl/2stLUY Bug: v8:7919 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I890a7e766cdd1be88db94844fb744f72823dba33 Reviewed-on: https://chromium-review.googlesource.com/1126099 Reviewed-by: Maya Lekova <[email protected]> Reviewed-by: Benedikt Meurer <[email protected]> Reviewed-by: Yang Guo <[email protected]> Commit-Queue: Benedikt Meurer <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54309} Refs: v8/v8@907d7bc PR-URL: nodejs#21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [turbofan] Remove optimization of default Promise capability functions. The JSCallReducer could in theory inline the default resolve and reject functions passed to the executor in the Promise constructor. But that inlining is almost never triggered because we don't have SFI based feedback in the CallIC. Also the use of the Promise constructor is discouraged, so we shouldn't really need to squeeze the last bit of performance out of this even in the future. Getting rid of this optimization will make significantly easier to implement the Swallowed Rejection Hook, as there's less churn on the TurboFan side then. Bug: v8:7919 Change-Id: If0c54f1c6c7ce95686cd74232be6b8693ac688c9 Reviewed-on: https://chromium-review.googlesource.com/1125926 Commit-Queue: Benedikt Meurer <[email protected]> Reviewed-by: Jaroslav Sevcik <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54210} Refs: v8/v8@2075910 PR-URL: nodejs#21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [promise] Implement Swallowed Rejection Hook. This extends the current Promise Rejection Hook with two new events kPromiseRejectAfterResolved kPromiseResolveAfterResolved which are used to detect (and signal) misuse of the Promise constructor. Specifically the common bug like new Promise((res, rej) => { res(1); throw new Error("something") }); where the error is silently swallowed by the Promise constructor without the user ever noticing can be caught via this hook. Doc: https://goo.gl/2stLUY Bug: v8:7919 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I890a7e766cdd1be88db94844fb744f72823dba33 Reviewed-on: https://chromium-review.googlesource.com/1126099 Reviewed-by: Maya Lekova <[email protected]> Reviewed-by: Benedikt Meurer <[email protected]> Reviewed-by: Yang Guo <[email protected]> Commit-Queue: Benedikt Meurer <[email protected]> Cr-Commit-Position: refs/heads/master@{nodejs#54309} Refs: v8/v8@907d7bc PR-URL: nodejs#21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Should this be backported to |
Original commit message: [turbofan] Remove optimization of default Promise capability functions. The JSCallReducer could in theory inline the default resolve and reject functions passed to the executor in the Promise constructor. But that inlining is almost never triggered because we don't have SFI based feedback in the CallIC. Also the use of the Promise constructor is discouraged, so we shouldn't really need to squeeze the last bit of performance out of this even in the future. Getting rid of this optimization will make significantly easier to implement the Swallowed Rejection Hook, as there's less churn on the TurboFan side then. Bug: v8:7919 Change-Id: If0c54f1c6c7ce95686cd74232be6b8693ac688c9 Reviewed-on: https://chromium-review.googlesource.com/1125926 Commit-Queue: Benedikt Meurer <[email protected]> Reviewed-by: Jaroslav Sevcik <[email protected]> Cr-Commit-Position: refs/heads/master@{#54210} Refs: v8/v8@2075910 Backport-PR-URL: #21668 PR-URL: #21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Original commit message: [promise] Implement Swallowed Rejection Hook. This extends the current Promise Rejection Hook with two new events kPromiseRejectAfterResolved kPromiseResolveAfterResolved which are used to detect (and signal) misuse of the Promise constructor. Specifically the common bug like new Promise((res, rej) => { res(1); throw new Error("something") }); where the error is silently swallowed by the Promise constructor without the user ever noticing can be caught via this hook. Doc: https://goo.gl/2stLUY Bug: v8:7919 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I890a7e766cdd1be88db94844fb744f72823dba33 Reviewed-on: https://chromium-review.googlesource.com/1126099 Reviewed-by: Maya Lekova <[email protected]> Reviewed-by: Benedikt Meurer <[email protected]> Reviewed-by: Yang Guo <[email protected]> Commit-Queue: Benedikt Meurer <[email protected]> Cr-Commit-Position: refs/heads/master@{#54309} Refs: v8/v8@907d7bc Backport-PR-URL: #21668 PR-URL: #21838 Refs: nodejs/promises-debugging#8 Reviewed-By: Gus Caplan <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yang Guo <[email protected]> Reviewed-By: Benedikt Meurer <[email protected]>
Cherry-picks two commits:
Refs: nodejs/promises-debugging#8
Being an API change, they are not eligible for upstream back-merge.
/cc @nodejs/v8-update @MayaLekova @nodejs/promises-debugging
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes