Title: [169132] branches/safari-538.34-branch/Source/_javascript_Core
Diff
Modified: branches/safari-538.34-branch/Source/_javascript_Core/ChangeLog (169131 => 169132)
--- branches/safari-538.34-branch/Source/_javascript_Core/ChangeLog 2014-05-20 20:57:17 UTC (rev 169131)
+++ branches/safari-538.34-branch/Source/_javascript_Core/ChangeLog 2014-05-20 20:57:23 UTC (rev 169132)
@@ -1,3 +1,28 @@
+2014-05-20 Matthew Hanson <[email protected]>
+
+ Merge r169094.
+
+ 2014-05-19 Mark Lam <[email protected]>
+
+ 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-16 Matthew Hanson <[email protected]>
Merge r168776.
Modified: branches/safari-538.34-branch/Source/_javascript_Core/jit/JITOperations.cpp (169131 => 169132)
--- branches/safari-538.34-branch/Source/_javascript_Core/jit/JITOperations.cpp 2014-05-20 20:57:17 UTC (rev 169131)
+++ branches/safari-538.34-branch/Source/_javascript_Core/jit/JITOperations.cpp 2014-05-20 20:57:23 UTC (rev 169132)
@@ -1019,25 +1019,21 @@
VM& vm = exec->vm();
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();
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
