<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>[169094] trunk/Source/JavaScriptCore</title>
</head>
<body>
<style type="text/css"><!--
#msg dl.meta { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dl.meta dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer, #logmsg { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; }
#msg dl a { font-weight: bold}
#msg dl a:link { color:#fc3; }
#msg dl a:active { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre { overflow: auto; background: #ffc; border: 1px #fa0 solid; padding: 6px; }
#logmsg { background: #ffc; border: 1px #fa0 solid; padding: 1em 1em 0 1em; }
#logmsg p, #logmsg pre, #logmsg blockquote { margin: 0 0 1em 0; }
#logmsg p, #logmsg li, #logmsg dt, #logmsg dd { line-height: 14pt; }
#logmsg h1, #logmsg h2, #logmsg h3, #logmsg h4, #logmsg h5, #logmsg h6 { margin: .5em 0; }
#logmsg h1:first-child, #logmsg h2:first-child, #logmsg h3:first-child, #logmsg h4:first-child, #logmsg h5:first-child, #logmsg h6:first-child { margin-top: 0; }
#logmsg ul, #logmsg ol { padding: 0; list-style-position: inside; margin: 0 0 0 1em; }
#logmsg ul { text-indent: -1em; padding-left: 1em; }#logmsg ol { text-indent: -1.5em; padding-left: 1.5em; }
#logmsg > ul, #logmsg > ol { margin: 0 0 1em 0; }
#logmsg pre { background: #eee; padding: 1em; }
#logmsg blockquote { border: 1px solid #fa0; border-left-width: 10px; padding: 1em 1em 0 1em; background: white;}
#logmsg dl { margin: 0; }
#logmsg dt { font-weight: bold; }
#logmsg dd { margin: 0; padding: 0 0 0.5em 0; }
#logmsg dd:before { content:'\00bb';}
#logmsg table { border-spacing: 0px; border-collapse: collapse; border-top: 4px solid #fa0; border-bottom: 1px solid #fa0; background: #fff; }
#logmsg table th { text-align: left; font-weight: normal; padding: 0.2em 0.5em; border-top: 1px dotted #fa0; }
#logmsg table td { text-align: right; border-top: 1px dotted #fa0; padding: 0.2em 0.5em; }
#logmsg table thead th { text-align: center; border-bottom: 1px solid #fa0; }
#logmsg table th.Corner { text-align: left; }
#logmsg hr { border: none 0; border-top: 2px dashed #fa0; height: 1px; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<div id="msg">
<dl class="meta">
<dt>Revision</dt> <dd><a href="http://trac.webkit.org/projects/webkit/changeset/169094">169094</a></dd>
<dt>Author</dt> <dd>mark.lam@apple.com</dd>
<dt>Date</dt> <dd>2014-05-19 19:03:47 -0700 (Mon, 19 May 2014)</dd>
</dl>
<h3>Log Message</h3>
<pre>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:</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceJavaScriptCoreChangeLog">trunk/Source/JavaScriptCore/ChangeLog</a></li>
<li><a href="#trunkSourceJavaScriptCorejitJITOperationscpp">trunk/Source/JavaScriptCore/jit/JITOperations.cpp</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourceJavaScriptCoreChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/ChangeLog (169093 => 169094)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/ChangeLog 2014-05-20 01:56:41 UTC (rev 169093)
+++ trunk/Source/JavaScriptCore/ChangeLog 2014-05-20 02:03:47 UTC (rev 169094)
</span><span class="lines">@@ -1,3 +1,24 @@
</span><ins>+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:
+
</ins><span class="cx"> 2014-05-19 Filip Pizlo <fpizlo@apple.com>
</span><span class="cx">
</span><span class="cx"> Take care of some ARM64 test failures
</span></span></pre></div>
<a id="trunkSourceJavaScriptCorejitJITOperationscpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/jit/JITOperations.cpp (169093 => 169094)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/jit/JITOperations.cpp 2014-05-20 01:56:41 UTC (rev 169093)
+++ trunk/Source/JavaScriptCore/jit/JITOperations.cpp 2014-05-20 02:03:47 UTC (rev 169094)
</span><span class="lines">@@ -1019,25 +1019,21 @@
</span><span class="cx"> VM& vm = exec->vm();
</span><span class="cx"> NativeCallFrameTracer tracer(&vm, exec);
</span><span class="cx">
</span><del>- // 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:
</del><ins>+ // 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:
</ins><span class="cx"> //
</span><span class="cx"> // - The optimized version of our code block being jettisoned by GC right after
</span><del>- // we concluded that we wanted to use it.
</del><ins>+ // we concluded that we wanted to use it, but have not planted it into the JS
+ // stack yet.
</ins><span class="cx"> //
</span><span class="cx"> // - An optimized version of our code block being installed just as we decided
</span><span class="cx"> // that it wasn't ready yet.
</span><span class="cx"> //
</span><del>- // 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.
- //
</del><span class="cx"> // Note that jettisoning won't happen if we already initiated OSR, because in
</span><span class="cx"> // that case we would have already planted the optimized code block into the JS
</span><span class="cx"> // stack.
</span><del>- DeferGC deferGC(vm.heap);
</del><ins>+ DeferGCForAWhile deferGC(vm.heap);
</ins><span class="cx">
</span><span class="cx"> CodeBlock* codeBlock = exec->codeBlock();
</span><span class="cx">
</span></span></pre>
</div>
</div>
</body>
</html>