Bug 212001 - OSR loop entry to iterator_next generic needs to CheckNotEmpty on m_next
Summary: OSR loop entry to iterator_next generic needs to CheckNotEmpty on m_next
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Keith Miller
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-05-17 13:25 PDT by Keith Miller
Modified: 2020-05-18 11:59 PDT (History)
6 users (show)

See Also:


Attachments
Patch (2.82 KB, patch)
2020-05-17 13:26 PDT, Keith Miller
no flags Details | Formatted Diff | Diff
Patch (3.38 KB, patch)
2020-05-17 13:57 PDT, Keith Miller
saam: review+
saam: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Miller 2020-05-17 13:25:12 PDT
OSR loop entry to iterator_next generic needs to CheckNotEmpty on m_next
Comment 1 Keith Miller 2020-05-17 13:26:16 PDT
Created attachment 399603 [details]
Patch
Comment 2 Keith Miller 2020-05-17 13:26:39 PDT
rdar://problem/62844069
Comment 3 Keith Miller 2020-05-17 13:57:52 PDT
Created attachment 399605 [details]
Patch
Comment 4 Saam Barati 2020-05-18 10:49:39 PDT
Comment on attachment 399605 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=399605&action=review

> Source/JavaScriptCore/ChangeLog:15
> +        If we happen to OSR enter into iterator_next during a for-of loop
> +        that has only profiled a generic iterator but is actually running
> +        a fast iterator we will incorrectly exit forward to the next
> +        getter checkpoint. This is because we don't check the next
> +        function is non empty when we only emit a generic iterator_next
> +        bytecode. The fix for this is to simply put a CheckNotEmpty at the
> +        top of the generic case. 99.9% of the time this check will be
> +        eliminated so it doesn't really cost anything.

the explanation you gave me in Slack is much clearer than this. I'd try to explain it like that in here.

> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:7000
> +                // Sanity check that we don't get here with a fast path during OSR entry.

I think this deserves a proper explanation. "Sanity check", to me, implies this should never happen. But it can happen, so let's describe how, and just say the below code can't handle the empty value.
Comment 5 Keith Miller 2020-05-18 11:56:54 PDT
Committed r261824: <https://trac.webkit.org/changeset/261824>
Comment 6 Keith Miller 2020-05-18 11:59:08 PDT
Comment on attachment 399605 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=399605&action=review

>> Source/JavaScriptCore/ChangeLog:15
>> +        eliminated so it doesn't really cost anything.
> 
> the explanation you gave me in Slack is much clearer than this. I'd try to explain it like that in here.

Done.

>> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:7000
>> +                // Sanity check that we don't get here with a fast path during OSR entry.
> 
> I think this deserves a proper explanation. "Sanity check", to me, implies this should never happen. But it can happen, so let's describe how, and just say the below code can't handle the empty value.

Ok, I added the description of how we could fail this check and that Call can't handle it without the check.