Title: [90875] trunk
Revision
90875
Author
[email protected]
Date
2011-07-12 17:53:17 -0700 (Tue, 12 Jul 2011)

Log Message

Overzealous type validation in method_check
https://bugs.webkit.org/show_bug.cgi?id=64415

Reviewed by Gavin Barraclough.

../../../../Volumes/Data/git/WebKit/OpenSource/LayoutTests:

Make sure we don't trip any assertions when caching access
to an InternalFunction

* fast/js/script-tests/method-check.js:

../../../../Volumes/Data/git/WebKit/OpenSource/Source/_javascript_Core:

method_check is essentially just a value look up
optimisation, but it internally stores the value
as a JSFunction, even though it never relies on
this fact.  Under GC validation however we end up
trying to enforce that assumption.  The fix is
simply to store the value as a correct supertype.

* bytecode/CodeBlock.h:
* dfg/DFGRepatch.cpp:
(JSC::DFG::dfgRepatchGetMethodFast):
(JSC::DFG::tryCacheGetMethod):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::patchMethodCallProto):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):

Modified Paths

Diff

Modified: trunk/LayoutTests/ChangeLog (90874 => 90875)


--- trunk/LayoutTests/ChangeLog	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/LayoutTests/ChangeLog	2011-07-13 00:53:17 UTC (rev 90875)
@@ -1,3 +1,15 @@
+2011-07-12  Oliver Hunt  <[email protected]>
+
+        Overzealous type validation in method_check
+        https://bugs.webkit.org/show_bug.cgi?id=64415
+
+        Reviewed by Gavin Barraclough.
+
+        Make sure we don't trip any assertions when caching access
+        to an InternalFunction
+
+        * fast/js/script-tests/method-check.js:
+
 2011-07-12  Joseph Pecoraro  <[email protected]>
 
         Unreviewed. Skipping a few tests which fail due to differing output

Modified: trunk/LayoutTests/fast/js/script-tests/method-check.js (90874 => 90875)


--- trunk/LayoutTests/fast/js/script-tests/method-check.js	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/LayoutTests/fast/js/script-tests/method-check.js	2011-07-13 00:53:17 UTC (rev 90875)
@@ -53,4 +53,8 @@
 totalizer.makeCall(addOneHundred);
 shouldBe('total', '200');
 
+// Check that we don't assert when method_check is applied to a non-JSFunction
+for (var i = 0; i < 10000; i++)
+    Array.constructor(1);
+
 var successfullyParsed = true;

Modified: trunk/Source/_javascript_Core/ChangeLog (90874 => 90875)


--- trunk/Source/_javascript_Core/ChangeLog	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/Source/_javascript_Core/ChangeLog	2011-07-13 00:53:17 UTC (rev 90875)
@@ -1,3 +1,27 @@
+2011-07-12  Oliver Hunt  <[email protected]>
+
+        Overzealous type validation in method_check
+        https://bugs.webkit.org/show_bug.cgi?id=64415
+
+        Reviewed by Gavin Barraclough.
+
+        method_check is essentially just a value look up
+        optimisation, but it internally stores the value
+        as a JSFunction, even though it never relies on
+        this fact.  Under GC validation however we end up
+        trying to enforce that assumption.  The fix is
+        simply to store the value as a correct supertype.
+
+        * bytecode/CodeBlock.h:
+        * dfg/DFGRepatch.cpp:
+        (JSC::DFG::dfgRepatchGetMethodFast):
+        (JSC::DFG::tryCacheGetMethod):
+        * jit/JIT.h:
+        * jit/JITPropertyAccess.cpp:
+        (JSC::JIT::patchMethodCallProto):
+        * jit/JITStubs.cpp:
+        (JSC::DEFINE_STUB_FUNCTION):
+
 2011-07-12  Filip Pizlo  <[email protected]>
 
         COLLECT_ON_EVERY_ALLOCATION no longer works.

Modified: trunk/Source/_javascript_Core/bytecode/CodeBlock.h (90874 => 90875)


--- trunk/Source/_javascript_Core/bytecode/CodeBlock.h	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/Source/_javascript_Core/bytecode/CodeBlock.h	2011-07-13 00:53:17 UTC (rev 90875)
@@ -146,7 +146,9 @@
         CodeLocationCall callReturnLocation;
         JITWriteBarrier<Structure> cachedStructure;
         JITWriteBarrier<Structure> cachedPrototypeStructure;
-        JITWriteBarrier<JSFunction> cachedFunction;
+        // We'd like this to actually be JSFunction, but InternalFunction and JSFunction
+        // don't have a common parent class and we allow specialisation on both
+        JITWriteBarrier<JSObjectWithGlobalObject> cachedFunction;
         JITWriteBarrier<JSObject> cachedPrototype;
         bool seen;
     };

Modified: trunk/Source/_javascript_Core/dfg/DFGRepatch.cpp (90874 => 90875)


--- trunk/Source/_javascript_Core/dfg/DFGRepatch.cpp	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/Source/_javascript_Core/dfg/DFGRepatch.cpp	2011-07-13 00:53:17 UTC (rev 90875)
@@ -161,7 +161,7 @@
         dfgRepatchCall(exec->codeBlock(), stubInfo.callReturnLocation, operationGetById);
 }
 
-static void dfgRepatchGetMethodFast(JSGlobalData* globalData, CodeBlock* codeBlock, MethodCallLinkInfo& methodInfo, JSFunction* callee, Structure* structure, JSObject* slotBaseObject)
+static void dfgRepatchGetMethodFast(JSGlobalData* globalData, CodeBlock* codeBlock, MethodCallLinkInfo& methodInfo, JSObjectWithGlobalObject* callee, Structure* structure, JSObject* slotBaseObject)
 {
     ScriptExecutable* owner = codeBlock->ownerExecutable();
     
@@ -190,7 +190,7 @@
         && (slotBaseObject = asObject(slot.slotBase()))->getPropertySpecificValue(exec, propertyName, specific)
         && specific) {
         
-        JSFunction* callee = (JSFunction*)specific;
+        JSObjectWithGlobalObject* callee = (JSObjectWithGlobalObject*)specific;
         
         // Since we're accessing a prototype in a loop, it's a good bet that it
         // should not be treated as a dictionary.

Modified: trunk/Source/_javascript_Core/jit/JIT.h (90874 => 90875)


--- trunk/Source/_javascript_Core/jit/JIT.h	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/Source/_javascript_Core/jit/JIT.h	2011-07-13 00:53:17 UTC (rev 90875)
@@ -238,7 +238,7 @@
 
         static void patchGetByIdSelf(CodeBlock* codeblock, StructureStubInfo*, Structure*, size_t cachedOffset, ReturnAddressPtr returnAddress);
         static void patchPutByIdReplace(CodeBlock* codeblock, StructureStubInfo*, Structure*, size_t cachedOffset, ReturnAddressPtr returnAddress, bool direct);
-        static void patchMethodCallProto(JSGlobalData&, CodeBlock* codeblock, MethodCallLinkInfo&, JSFunction*, Structure*, JSObject*, ReturnAddressPtr);
+        static void patchMethodCallProto(JSGlobalData&, CodeBlock* codeblock, MethodCallLinkInfo&, JSObjectWithGlobalObject*, Structure*, JSObject*, ReturnAddressPtr);
 
         static void compilePatchGetArrayLength(JSGlobalData* globalData, CodeBlock* codeBlock, ReturnAddressPtr returnAddress)
         {

Modified: trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp (90874 => 90875)


--- trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/Source/_javascript_Core/jit/JITPropertyAccess.cpp	2011-07-13 00:53:17 UTC (rev 90875)
@@ -1036,7 +1036,7 @@
     failureCases.append(branchPtr(NotEqual, Address(regT3, JSCell::structureOffset()), TrustedImmPtr(prototype.asCell()->structure())));
 }
 
-void JIT::patchMethodCallProto(JSGlobalData& globalData, CodeBlock* codeBlock, MethodCallLinkInfo& methodCallLinkInfo, JSFunction* callee, Structure* structure, JSObject* proto, ReturnAddressPtr returnAddress)
+void JIT::patchMethodCallProto(JSGlobalData& globalData, CodeBlock* codeBlock, MethodCallLinkInfo& methodCallLinkInfo, JSObjectWithGlobalObject* callee, Structure* structure, JSObject* proto, ReturnAddressPtr returnAddress)
 {
     RepatchBuffer repatchBuffer(codeBlock);
     

Modified: trunk/Source/_javascript_Core/jit/JITStubs.cpp (90874 => 90875)


--- trunk/Source/_javascript_Core/jit/JITStubs.cpp	2011-07-13 00:52:11 UTC (rev 90874)
+++ trunk/Source/_javascript_Core/jit/JITStubs.cpp	2011-07-13 00:53:17 UTC (rev 90875)
@@ -1529,7 +1529,7 @@
         && specific
         ) {
 
-        JSFunction* callee = (JSFunction*)specific;
+        JSObjectWithGlobalObject* callee = (JSObjectWithGlobalObject*)specific;
 
         // Since we're accessing a prototype in a loop, it's a good bet that it
         // should not be treated as a dictionary.
_______________________________________________
webkit-changes mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes

Reply via email to