Bug 172098

Summary: [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
Product: WebKit Reporter: Yusuke Suzuki <ysuzuki>
Component: JavaScriptCoreAssignee: Yusuke Suzuki <ysuzuki>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, buildbot, commit-queue, fpizlo, pvollan, rniwa, saam, sam
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 172293    
Bug Blocks: 171637, 172267    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Archive of layout-test-results from ews123 for ios-simulator-wk2
none
Patch
saam: review+, buildbot: commit-queue-
Archive of layout-test-results from ews105 for mac-elcapitan-wk2
none
Archive of layout-test-results from ews101 for mac-elcapitan
none
Patch none

Description Yusuke Suzuki 2017-05-14 20:06:03 PDT
CheckDOM is not DOMJIT specific thing. It performs subclass-of with the given ClassInfo*.
We can expand it to accept arbitrary ClassInfo*.
And ClassInfo* itself should have a way to teach DFG the way to perform faster class info check instead of having checkDOM function in each DOMJIT annotation.
Comment 1 Yusuke Suzuki 2017-05-14 22:58:13 PDT
Created attachment 310110 [details]
Patch
Comment 2 Build Bot 2017-05-14 23:02:33 PDT
Attachment 310110 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/JSTypedArrays.cpp:37:  preprocessor directives (e.g., #ifdef, #define, #import) should never be indented.  [whitespace/indent] [4]
Total errors found: 1 in 302 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 Yusuke Suzuki 2017-05-15 02:52:38 PDT
Created attachment 310125 [details]
Patch
Comment 4 Build Bot 2017-05-15 02:56:56 PDT
Attachment 310125 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/JSTypedArrays.cpp:37:  preprocessor directives (e.g., #ifdef, #define, #import) should never be indented.  [whitespace/indent] [4]
Total errors found: 1 in 303 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 5 Saam Barati 2017-05-16 18:13:04 PDT
Comment on attachment 310125 [details]
Patch

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

> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:7923
> +        m_jit.loadPtr(CCallHelpers::Address(specifiedGPR, ClassInfo::offsetOfParentClass()), specifiedGPR);

This looks backwards. Don't you want to check if otherGPR is a subclass of specifiedGPR, not the other way around?
Comment 6 Yusuke Suzuki 2017-05-16 20:03:16 PDT
Created attachment 310345 [details]
Patch
Comment 7 Build Bot 2017-05-16 20:07:30 PDT
Attachment 310345 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/JSTypedArrays.cpp:37:  preprocessor directives (e.g., #ifdef, #define, #import) should never be indented.  [whitespace/indent] [4]
Total errors found: 1 in 309 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 8 Build Bot 2017-05-16 23:38:19 PDT
Comment on attachment 310345 [details]
Patch

Attachment 310345 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/3757346

New failing tests:
http/tests/loading/resourceLoadStatistics/non-prevalent-resource-without-user-interaction.html
Comment 9 Build Bot 2017-05-16 23:38:29 PDT
Created attachment 310353 [details]
Archive of layout-test-results from ews123 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews123  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.6
Comment 10 Yusuke Suzuki 2017-05-16 23:51:10 PDT
Created attachment 310354 [details]
Patch
Comment 11 Build Bot 2017-05-16 23:54:07 PDT
Attachment 310354 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/JSTypedArrays.cpp:37:  preprocessor directives (e.g., #ifdef, #define, #import) should never be indented.  [whitespace/indent] [4]
Total errors found: 1 in 309 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 12 Build Bot 2017-05-17 01:29:17 PDT
Comment on attachment 310354 [details]
Patch

Attachment 310354 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/3759002

New failing tests:
http/tests/loading/resourceLoadStatistics/non-prevalent-resource-without-user-interaction.html
Comment 13 Build Bot 2017-05-17 01:29:19 PDT
Created attachment 310358 [details]
Archive of layout-test-results from ews105 for mac-elcapitan-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105  Port: mac-elcapitan-wk2  Platform: Mac OS X 10.11.6
Comment 14 Build Bot 2017-05-17 03:21:23 PDT
Comment on attachment 310354 [details]
Patch

Attachment 310354 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/3760688

New failing tests:
http/tests/appcache/404-resource-with-slow-main-resource.php
Comment 15 Build Bot 2017-05-17 03:21:24 PDT
Created attachment 310370 [details]
Archive of layout-test-results from ews101 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-elcapitan  Platform: Mac OS X 10.11.6
Comment 16 Saam Barati 2017-05-17 13:51:07 PDT
Comment on attachment 310354 [details]
Patch

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

r=me

> Source/JavaScriptCore/ChangeLog:18
> +        One problem is that it enlarges the size of ClassInfo.
> +        But this is the best place to put this function pointer.

I don't think this will matter much in practice, since ClassInfo size is bounded per process.

> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:7931
> +    RefPtr<DOMJIT::Patchpoint> patchpoint = classInfo->checkSubClassPatchpoint();

Style nit: It seems weird we're still calling this a DOMJIT::Patchpoint even though the function is called checkSubClassPatchpoint.

> Source/JavaScriptCore/runtime/ClassInfo.cpp:33
> +void ClassInfo::dump(PrintStream& out) const

nice!

> Source/JavaScriptCore/runtime/ClassInfo.h:214
> +    JS_EXPORT_PRIVATE void dump(PrintStream&) const;

Is this the WTF dataLog compatible way of printing?
Comment 17 Yusuke Suzuki 2017-05-17 21:38:22 PDT
Comment on attachment 310354 [details]
Patch

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

>> Source/JavaScriptCore/ChangeLog:18
>> +        But this is the best place to put this function pointer.
> 
> I don't think this will matter much in practice, since ClassInfo size is bounded per process.

OK.

>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:7931
>> +    RefPtr<DOMJIT::Patchpoint> patchpoint = classInfo->checkSubClassPatchpoint();
> 
> Style nit: It seems weird we're still calling this a DOMJIT::Patchpoint even though the function is called checkSubClassPatchpoint.

Yeah, we can move this out from DOMJIT directory. Actually, I think it is useful.

>> Source/JavaScriptCore/runtime/ClassInfo.h:214
>> +    JS_EXPORT_PRIVATE void dump(PrintStream&) const;
> 
> Is this the WTF dataLog compatible way of printing?

Yes. dataLog will call stderr printstream's print(...). And it will invoke `value.dump(out)`.
Comment 18 Yusuke Suzuki 2017-05-17 21:41:08 PDT
Comment on attachment 310354 [details]
Patch

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

>>> Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:7931
>>> +    RefPtr<DOMJIT::Patchpoint> patchpoint = classInfo->checkSubClassPatchpoint();
>> 
>> Style nit: It seems weird we're still calling this a DOMJIT::Patchpoint even though the function is called checkSubClassPatchpoint.
> 
> Yeah, we can move this out from DOMJIT directory. Actually, I think it is useful.

To move this out of domjit directory, we need to move many DOMJIT files (DOMJITPatchpointParam etc.).
So, I would like to do this in a separate patch. https://bugs.webkit.org/show_bug.cgi?id=172260
Comment 19 Yusuke Suzuki 2017-05-17 21:59:50 PDT
Committed r217031: <http://trac.webkit.org/changeset/217031>
Comment 20 Yusuke Suzuki 2017-05-17 22:08:08 PDT
Committed r217032: <http://trac.webkit.org/changeset/217032>
Comment 21 Yusuke Suzuki 2017-05-17 23:57:48 PDT
Committed r217037: <http://trac.webkit.org/changeset/217037>
Comment 22 Alexey Proskuryakov 2017-05-18 09:46:54 PDT
Windows build remains broken. How did this get landed despite EWS detecting failure?

WebCore.lib(JSNodeDOMJIT.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSNode::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll) [C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
WebCore.lib(JSDocumentDOMJIT.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSDocument::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll) [C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
     Creating library C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/TestWebCoreLib.lib and object C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/TestWebCoreLib.exp
C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\bin32\TestWebCoreLib.dll : fatal error LNK1169: one or more multiply defined symbols found [C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
WebCore.lib(JSNodeDOMJIT.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSNode::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll) [C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
WebCore.lib(JSDocumentDOMJIT.obj) : error LNK2005: "public: static class WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl WebCore::JSDocument::checkSubClassPatchpoint(void)" (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll) [C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
     Creating library C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/TestWebKitLib.lib and object C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/TestWebKitLib.exp
C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\bin32\TestWebKitLib.dll : fatal error LNK1169: one or more multiply defined symbols found [C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
Comment 23 Yusuke Suzuki 2017-05-18 10:22:02 PDT
(In reply to Alexey Proskuryakov from comment #22)
> Windows build remains broken. How did this get landed despite EWS detecting
> failure?
> 
> WebCore.lib(JSNodeDOMJIT.obj) : error LNK2005: "public: static class
> WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> WebCore::JSNode::checkSubClassPatchpoint(void)"
> (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JS
> C@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> [C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
> WebCore.lib(JSDocumentDOMJIT.obj) : error LNK2005: "public: static class
> WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> WebCore::JSDocument::checkSubClassPatchpoint(void)"
> (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJI
> T@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> [C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
>      Creating library
> C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> TestWebCoreLib.lib and object
> C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> TestWebCoreLib.exp
> C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\bin32\TestWebCoreLib.dll : fatal error
> LNK1169: one or more multiply defined symbols found
> [C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
> WebCore.lib(JSNodeDOMJIT.obj) : error LNK2005: "public: static class
> WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> WebCore::JSNode::checkSubClassPatchpoint(void)"
> (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JS
> C@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> [C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
> WebCore.lib(JSDocumentDOMJIT.obj) : error LNK2005: "public: static class
> WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> WebCore::JSDocument::checkSubClassPatchpoint(void)"
> (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJI
> T@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> [C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
>      Creating library
> C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> TestWebKitLib.lib and object
> C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> TestWebKitLib.exp
> C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\bin32\TestWebKitLib.dll : fatal error
> LNK1169: one or more multiply defined symbols found
> [C:\cygwin\home\buildbot\slave\win-
> release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]

We are now tracking it in bug 172267. The problem is that this is highly Windows specific...
Does any Windows folks know about this super strange behavior?
Comment 24 Brent Fulgham 2017-05-18 10:32:45 PDT
(In reply to Yusuke Suzuki from comment #23)
> (In reply to Alexey Proskuryakov from comment #22)
> > Windows build remains broken. How did this get landed despite EWS detecting
> > failure?
> > 
> > WebCore.lib(JSNodeDOMJIT.obj) : error LNK2005: "public: static class
> > WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> > WebCore::JSNode::checkSubClassPatchpoint(void)"
> > (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JS
> > C@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> > [C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
> > WebCore.lib(JSDocumentDOMJIT.obj) : error LNK2005: "public: static class
> > WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> > WebCore::JSDocument::checkSubClassPatchpoint(void)"
> > (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJI
> > T@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> > [C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
> >      Creating library
> > C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> > TestWebCoreLib.lib and object
> > C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> > TestWebCoreLib.exp
> > C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\bin32\TestWebCoreLib.dll : fatal error
> > LNK1169: one or more multiply defined symbols found
> > [C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebCoreLib.vcxproj]
> > WebCore.lib(JSNodeDOMJIT.obj) : error LNK2005: "public: static class
> > WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> > WebCore::JSNode::checkSubClassPatchpoint(void)"
> > (?checkSubClassPatchpoint@JSNode@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJIT@JS
> > C@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> > [C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
> > WebCore.lib(JSDocumentDOMJIT.obj) : error LNK2005: "public: static class
> > WTF::RefPtr<class JSC::DOMJIT::Patchpoint> __cdecl
> > WebCore::JSDocument::checkSubClassPatchpoint(void)"
> > (?checkSubClassPatchpoint@JSDocument@WebCore@@SA?AV?$RefPtr@VPatchpoint@DOMJI
> > T@JSC@@@WTF@@XZ) already defined in WebKit.lib(WebKit.dll)
> > [C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
> >      Creating library
> > C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> > TestWebKitLib.lib and object
> > C:/cygwin/home/buildbot/slave/win-release/build/WebKitBuild/Release/lib32/
> > TestWebKitLib.exp
> > C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\bin32\TestWebKitLib.dll : fatal error
> > LNK1169: one or more multiply defined symbols found
> > [C:\cygwin\home\buildbot\slave\win-
> > release\build\WebKitBuild\Release\Tools\TestWebKitAPI\TestWebKitLib.vcxproj]
> 
> We are now tracking it in bug 172267. The problem is that this is highly
> Windows specific...
> Does any Windows folks know about this super strange behavior?

I think we should roll this out until a fix is available. We are losing Windows testing support at present.
Comment 25 WebKit Commit Bot 2017-05-18 10:37:59 PDT
Re-opened since this is blocked by bug 172293
Comment 26 Yusuke Suzuki 2017-05-19 02:19:41 PDT
Created attachment 310637 [details]
Patch
Comment 27 Yusuke Suzuki 2017-05-19 02:23:33 PDT
Committed r217108: <http://trac.webkit.org/changeset/217108>