There's no need for VMTraps::maybeNeedHandling() to mask the VMTraps bits for events. Under normal circumstances, there are no traps firing and the traps bits are 0 anyway. We should optimize for this and do away with the masking. Clients who use VMTraps::maybeNeedHandling() should and current does call VMTraps::needHandling() to get the real story on whether there are actually traps to handle or not. Hence, the masking in VMTraps::maybeNeedHandling() is also not needed for correctness.
Created attachment 453916 [details] proposed patch.
Comment on attachment 453916 [details] proposed patch. Going back to r?. They’re non zero when we defer, which may happen frequently?
(In reply to Saam Barati from comment #2) > Comment on attachment 453916 [details] > proposed patch. > > Going back to r?. They’re non zero when we defer, which may happen > frequently? Maybe not frequently enough though. Might be worth just giving a bit of thought to defer% to non-defer%
(In reply to Saam Barati from comment #3) > (In reply to Saam Barati from comment #2) > > Comment on attachment 453916 [details] > > proposed patch. > > > > Going back to r?. They’re non zero when we defer, which may happen > > frequently? > > Maybe not frequently enough though. Might be worth just giving a bit of > thought to defer% to non-defer% I think that would be rare in a few sites only. We shouldn't be penalizing all exception check sites to favor just a few defer sites. Plus if bots show a regression, we can just roll this back.
Comment on attachment 453916 [details] proposed patch. r=me
Comment on attachment 453916 [details] proposed patch. Thanks for the review.
Committed r290871 (248102@main): <https://commits.webkit.org/248102@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 453916 [details].
<rdar://problem/89861322>