Title: [236495] trunk
Revision
236495
Author
[email protected]
Date
2018-09-25 20:14:09 -0700 (Tue, 25 Sep 2018)

Log Message

Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=189940
<rdar://problem/43640987>

Reviewed by Mark Lam.

JSTests:

* stress/use-baseline-codeblock-materialize-osr-exit.js: Added.

Source/_javascript_Core:

We were calling baselineCodeBlockForOriginAndBaselineCodeBlock with the FTL
CodeBlock. There is nothing semantically wrong with doing that (except for
poor naming), however, the poor naming here led us to make a real semantic
mistake. We wanted the baseline CodeBlock's constant pool, but we were
accessing the FTL CodeBlock's constant pool accidentally. We need to
access the baseline CodeBlock's constant pool when we update the NewArrayBuffer
constant value.

* bytecode/InlineCallFrame.h:
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):

Modified Paths

Added Paths

Diff

Modified: trunk/JSTests/ChangeLog (236494 => 236495)


--- trunk/JSTests/ChangeLog	2018-09-26 02:33:02 UTC (rev 236494)
+++ trunk/JSTests/ChangeLog	2018-09-26 03:14:09 UTC (rev 236495)
@@ -1,3 +1,13 @@
+2018-09-25  Saam Barati  <[email protected]>
+
+        Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock
+        https://bugs.webkit.org/show_bug.cgi?id=189940
+        <rdar://problem/43640987>
+
+        Reviewed by Mark Lam.
+
+        * stress/use-baseline-codeblock-materialize-osr-exit.js: Added.
+
 2018-09-24  Saam Barati  <[email protected]>
 
         Array.prototype.indexOf fast path needs to ensure the length is still valid after performing effects

Added: trunk/JSTests/stress/use-baseline-codeblock-materialize-osr-exit.js (0 => 236495)


--- trunk/JSTests/stress/use-baseline-codeblock-materialize-osr-exit.js	                        (rev 0)
+++ trunk/JSTests/stress/use-baseline-codeblock-materialize-osr-exit.js	2018-09-26 03:14:09 UTC (rev 236495)
@@ -0,0 +1,13 @@
+//@ runDefault("--jitPolicyScale=0")
+
+function foo() {
+    let j = 0;
+    let arr = [0];
+    arr.foo = 0;
+    for (var i = 0; i < 1024; i++) {
+        arr[0] = new Array(1024);
+    }
+}
+
+foo();
+foo();

Modified: trunk/Source/_javascript_Core/ChangeLog (236494 => 236495)


--- trunk/Source/_javascript_Core/ChangeLog	2018-09-26 02:33:02 UTC (rev 236494)
+++ trunk/Source/_javascript_Core/ChangeLog	2018-09-26 03:14:09 UTC (rev 236495)
@@ -1,3 +1,24 @@
+2018-09-25  Saam Barati  <[email protected]>
+
+        Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock
+        https://bugs.webkit.org/show_bug.cgi?id=189940
+        <rdar://problem/43640987>
+
+        Reviewed by Mark Lam.
+
+        We were calling baselineCodeBlockForOriginAndBaselineCodeBlock with the FTL
+        CodeBlock. There is nothing semantically wrong with doing that (except for
+        poor naming), however, the poor naming here led us to make a real semantic
+        mistake. We wanted the baseline CodeBlock's constant pool, but we were
+        accessing the FTL CodeBlock's constant pool accidentally. We need to
+        access the baseline CodeBlock's constant pool when we update the NewArrayBuffer
+        constant value.
+
+        * bytecode/InlineCallFrame.h:
+        (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
+        * ftl/FTLOperations.cpp:
+        (JSC::FTL::operationMaterializeObjectInOSR):
+
 2018-09-25  Joseph Pecoraro  <[email protected]>
 
         Web Inspector: Stricter block syntax in generated ObjC protocol interfaces

Modified: trunk/Source/_javascript_Core/bytecode/InlineCallFrame.h (236494 => 236495)


--- trunk/Source/_javascript_Core/bytecode/InlineCallFrame.h	2018-09-26 02:33:02 UTC (rev 236494)
+++ trunk/Source/_javascript_Core/bytecode/InlineCallFrame.h	2018-09-26 03:14:09 UTC (rev 236495)
@@ -240,6 +240,7 @@
 
 inline CodeBlock* baselineCodeBlockForOriginAndBaselineCodeBlock(const CodeOrigin& codeOrigin, CodeBlock* baselineCodeBlock)
 {
+    ASSERT(baselineCodeBlock->jitType() == JITCode::BaselineJIT);
     if (codeOrigin.inlineCallFrame)
         return baselineCodeBlockForInlineCallFrame(codeOrigin.inlineCallFrame);
     return baselineCodeBlock;

Modified: trunk/Source/_javascript_Core/ftl/FTLOperations.cpp (236494 => 236495)


--- trunk/Source/_javascript_Core/ftl/FTLOperations.cpp	2018-09-26 02:33:02 UTC (rev 236494)
+++ trunk/Source/_javascript_Core/ftl/FTLOperations.cpp	2018-09-26 03:14:09 UTC (rev 236495)
@@ -225,7 +225,7 @@
         RELEASE_ASSERT(table);
 
         CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(
-            materialization->origin(), exec->codeBlock());
+            materialization->origin(), exec->codeBlock()->baselineAlternative());
         Structure* structure = codeBlock->globalObject()->activationStructure();
 
         // It doesn't matter what values we initialize as bottom values inside the activation constructor because
@@ -286,7 +286,7 @@
                 return ClonedArguments::createWithMachineFrame(exec, exec, ArgumentsMode::Cloned);
             case PhantomCreateRest: {
                 CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(
-                    materialization->origin(), exec->codeBlock());
+                    materialization->origin(), exec->codeBlock()->baselineAlternative());
 
                 unsigned numberOfArgumentsToSkip = codeBlock->numberOfArgumentsToSkip();
                 JSGlobalObject* globalObject = codeBlock->globalObject();
@@ -330,7 +330,7 @@
         RELEASE_ASSERT(callee);
         
         CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(
-            materialization->origin(), exec->codeBlock());
+            materialization->origin(), exec->codeBlock()->baselineAlternative());
         
         // We have an inline frame and we have all of the data we need to recreate it.
         switch (materialization->type()) {
@@ -473,7 +473,7 @@
 
         // For now, we use array allocation profile in the actual CodeBlock. It is OK since current NewArrayBuffer
         // and PhantomNewArrayBuffer are always bound to a specific op_new_array_buffer.
-        CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(materialization->origin(), exec->codeBlock());
+        CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(materialization->origin(), exec->codeBlock()->baselineAlternative());
         Instruction* currentInstruction = &codeBlock->instructions()[materialization->origin().bytecodeIndex];
         RELEASE_ASSERT(Interpreter::getOpcodeID(currentInstruction[0].u.opcode) == op_new_array_buffer);
         auto* newArrayBuffer = bitwise_cast<OpNewArrayBuffer*>(currentInstruction);
@@ -506,7 +506,7 @@
 
     case PhantomNewArrayWithSpread: {
         CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(
-            materialization->origin(), exec->codeBlock());
+            materialization->origin(), exec->codeBlock()->baselineAlternative());
         JSGlobalObject* globalObject = codeBlock->globalObject();
         Structure* structure = globalObject->arrayStructureForIndexingTypeDuringAllocation(ArrayWithContiguous);
 
@@ -585,7 +585,7 @@
             }
         }
         RELEASE_ASSERT(regExp);
-        CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(materialization->origin(), exec->codeBlock());
+        CodeBlock* codeBlock = baselineCodeBlockForOriginAndBaselineCodeBlock(materialization->origin(), exec->codeBlock()->baselineAlternative());
         Structure* structure = codeBlock->globalObject()->regExpStructure();
         return RegExpObject::create(vm, structure, regExp);
     }
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to