Changeset 169094 in webkit

Timestamp:

May 19, 2014 7:03:47 PM (10 years ago)

Author:

mark.lam@apple.com

Message:

operationOptimize() should defer the GC for a while.
<​https://webkit.org/b/133103>

Reviewed by Filip Pizlo.

Currently, operationOptimize() only defers the GC until its end. As a result,
a GC may be triggered just before we return from operationOptimize(), and it may
jettison the optimize codeBlock that we're planning to OSR enter into when we
return from this function. This is because the OSR entry on-ramp code hasn't
been executed yet, and hence, there is not yet a reference to this new codeBlock
from the stack, and there won't be until we've had a chance to return out of
operationOptimize() to run the OSR entry on-ramp code.

This issue is now fixed by using DeferGCForAWhile instead of DeferGC. This
ensures that the GC will be deferred until after the OSR entry on-ramp can be
executed.

• jit/JITOperations.cpp:

Location:

trunk/Source/JavaScriptCore

Files:

• ChangeLog (modified) (1 diff)
• jit/JITOperations.cpp (modified) (1 diff)

trunk/Source/JavaScriptCore/ChangeLog

@@ +1 @@
+2014-05-19  Mark Lam  <mark.lam@apple.com>
+
+        operationOptimize() should defer the GC for a while.
+        <https://webkit.org/b/133103>
+
+        Reviewed by Filip Pizlo.
+
+        Currently, operationOptimize() only defers the GC until its end.  As a result,
+        a GC may be triggered just before we return from operationOptimize(), and it may
+        jettison the optimize codeBlock that we're planning to OSR enter into when we
+        return from this function.  This is because the OSR entry on-ramp code hasn't
+        been executed yet, and hence, there is not yet a reference to this new codeBlock
+        from the stack, and there won't be until we've had a chance to return out of
+        operationOptimize() to run the OSR entry on-ramp code.
+
+        This issue is now fixed by using DeferGCForAWhile instead of DeferGC.  This
+        ensures that the GC will be deferred until after the OSR entry on-ramp can be
+        executed.
+
+        * jit/JITOperations.cpp:
+
 2014-05-19  Filip Pizlo  <fpizlo@apple.com>
 

trunk/Source/JavaScriptCore/jit/JITOperations.cpp

@@ -1020 +1020 @@
     NativeCallFrameTracer tracer(&vm, exec);
 
-    // Defer GC so that it doesn't run between when we enter into this slow path and
-    // when we figure out the state of our code block. This prevents a number of
-    // awkward reentrancy scenarios, including:
+    // Defer GC for a while so that it doesn't run between when we enter into this
+    // slow path and when we figure out the state of our code block. This prevents
+    // a number of awkward reentrancy scenarios, including:
     //
     // - The optimized version of our code block being jettisoned by GC right after
-    //   we concluded that we wanted to use it.
+    //   we concluded that we wanted to use it, but have not planted it into the JS
+    //   stack yet.
     //
     // - An optimized version of our code block being installed just as we decided
     //   that it wasn't ready yet.
     //
-    // This still leaves the following: anytime we return from cti_optimize, we may
-    // GC, and the GC may either jettison the optimized version of our code block,
-    // or it may install the optimized version of our code block even though we
-    // concluded that it wasn't ready yet.
-    //
     // Note that jettisoning won't happen if we already initiated OSR, because in
     // that case we would have already planted the optimized code block into the JS
     // stack.
-    DeferGC deferGC(vm.heap);
+    DeferGCForAWhile deferGC(vm.heap);
     
     CodeBlock* codeBlock = exec->codeBlock();