<!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>[282663] trunk</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/282663">282663</a></dd>
<dt>Author</dt> <dd>justin_michaud@apple.com</dd>
<dt>Date</dt> <dd>2021-09-17 08:56:53 -0700 (Fri, 17 Sep 2021)</dd>
</dl>

<h3>Log Message</h3>
<pre>PutByVal and PutPrivateName ICs should emit a write barrier if a butterfly might be allocated
https://bugs.webkit.org/show_bug.cgi?id=230378

Reviewed by Yusuke Suzuki.

Right now, PutByVal and PutPrivateName check the value type to determine
if a write barrier is needed. For example, putting a primitive is considered
to not require a write barrier. This makes sense, except for the case when we
might allocate or re-allocate a butterfly in the IC. This does not emit a write
barrier, and so the GC might miss the new butterfly. That is somewhat undesirable.
This is a temporary conservative fix. If we don't write to the butterfly pointer,
then we still don't need a write barrier; this work is captured by
https://bugs.webkit.org/show_bug.cgi?id=230377

* dfg/DFGStoreBarrierInsertionPhase.cpp:</pre>

<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceJavaScriptCoreChangeLog">trunk/Source/JavaScriptCore/ChangeLog</a></li>
<li><a href="#trunkSourceJavaScriptCoredfgDFGStoreBarrierInsertionPhasecpp">trunk/Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp</a></li>
</ul>

<h3>Added Paths</h3>
<ul>
<li><a href="#trunkJSTestsstressputbyvalicwritebarrierjs">trunk/JSTests/stress/put-by-val-ic-write-barrier.js</a></li>
<li><a href="#trunkJSTestsstressputprivatenameicwritebarrierjs">trunk/JSTests/stress/put-private-name-ic-write-barrier.js</a></li>
</ul>

</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkJSTestsstressputbyvalicwritebarrierjs"></a>
<div class="addfile"><h4>Added: trunk/JSTests/stress/put-by-val-ic-write-barrier.js (0 => 282663)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/JSTests/stress/put-by-val-ic-write-barrier.js                              (rev 0)
+++ trunk/JSTests/stress/put-by-val-ic-write-barrier.js 2021-09-17 15:56:53 UTC (rev 282663)
</span><span class="lines">@@ -0,0 +1,22 @@
</span><ins>+//@ runDefault("--collectContinuously=1", "--useAccessInlining=0", "--verifyGC=1")
+
+function PutByValICPrimitive() {
+    let leak = []
+
+    function doByVal(o, s) {
+        o[s] = 1337
+    }
+    noInline(doByVal)
+
+    for (let i = 0; i < 1000000; ++i) {
+        let o1 = {a: 1, b: 2}
+        let o2 = {a: 1, b: 2}
+        let o3 = {a: 1, b: 2}
+        doByVal(o1, "x")
+        doByVal(o2, "y")
+        doByVal(o3, "z")
+        leak.push(o1, o2, o3)
+    }
+}
+noInline(PutByValICPrimitive)
+PutByValICPrimitive()
</ins><span class="cx">\ No newline at end of file
</span></span></pre></div>
<a id="trunkJSTestsstressputprivatenameicwritebarrierjs"></a>
<div class="addfile"><h4>Added: trunk/JSTests/stress/put-private-name-ic-write-barrier.js (0 => 282663)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/JSTests/stress/put-private-name-ic-write-barrier.js                                (rev 0)
+++ trunk/JSTests/stress/put-private-name-ic-write-barrier.js   2021-09-17 15:56:53 UTC (rev 282663)
</span><span class="lines">@@ -0,0 +1,29 @@
</span><ins>+//@ runDefault("--collectContinuously=1", "--usePolyvariantDevirtualization=0", "--forceDebuggerBytecodeGeneration=1", "--verifyGC=1")
+// UsePolyvariantDevirtualization gives us a PutPrivateName (not byID) while still letting us generate an IC with only one AccessCase
+// DebuggerBytecodeGeneration seems to give the GC more time to interrupt the put because it forces reads from the stack 
+
+function PutPrivateNameIC() {
+    let leak = []
+
+    class A {
+        constructor() {
+            this.a = 0
+        }
+    }
+    noInline(A)
+
+    class B extends A {
+        #b
+        #c
+    }
+    noInline(B)
+
+    for (let i = 0; i < 1000000; ++i) {
+        let b1 = new B
+        let b2 = new B
+        let b3 = new B
+        leak.push(b1, b2, b3)
+    }
+}
+noInline(PutPrivateNameIC)
+PutPrivateNameIC()
</ins><span class="cx">\ No newline at end of file
</span></span></pre></div>
<a id="trunkSourceJavaScriptCoreChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/ChangeLog (282662 => 282663)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/ChangeLog    2021-09-17 15:03:12 UTC (rev 282662)
+++ trunk/Source/JavaScriptCore/ChangeLog       2021-09-17 15:56:53 UTC (rev 282663)
</span><span class="lines">@@ -1,3 +1,21 @@
</span><ins>+2021-09-17  Justin Michaud  <justin_michaud@apple.com>
+
+        PutByVal and PutPrivateName ICs should emit a write barrier if a butterfly might be allocated
+        https://bugs.webkit.org/show_bug.cgi?id=230378
+
+        Reviewed by Yusuke Suzuki.
+
+        Right now, PutByVal and PutPrivateName check the value type to determine 
+        if a write barrier is needed. For example, putting a primitive is considered 
+        to not require a write barrier. This makes sense, except for the case when we 
+        might allocate or re-allocate a butterfly in the IC. This does not emit a write 
+        barrier, and so the GC might miss the new butterfly. That is somewhat undesirable. 
+        This is a temporary conservative fix. If we don't write to the butterfly pointer,
+        then we still don't need a write barrier; this work is captured by 
+        https://bugs.webkit.org/show_bug.cgi?id=230377
+
+        * dfg/DFGStoreBarrierInsertionPhase.cpp:
+
</ins><span class="cx"> 2021-09-16  Saam Barati  <sbarati@apple.com>
</span><span class="cx"> 
</span><span class="cx">         Don't throw an exception in the middle of linking a CodeBlock
</span></span></pre></div>
<a id="trunkSourceJavaScriptCoredfgDFGStoreBarrierInsertionPhasecpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp (282662 => 282663)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp        2021-09-17 15:03:12 UTC (rev 282662)
+++ trunk/Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp   2021-09-17 15:56:53 UTC (rev 282663)
</span><span class="lines">@@ -237,9 +237,9 @@
</span><span class="cx">                 case Array::BigInt64Array:
</span><span class="cx">                 case Array::BigUint64Array: {
</span><span class="cx">                     Edge child1 = m_graph.varArgChild(m_node, 0);
</span><del>-                    Edge child3 = m_graph.varArgChild(m_node, 2);
</del><span class="cx">                     if (!m_graph.m_slowPutByVal.contains(m_node) && (child1.useKind() == CellUse || child1.useKind() == KnownCellUse))
</span><del>-                        considerBarrier(child1, child3);
</del><ins>+                        // FIXME: there are some cases where we can avoid a store barrier by considering the value https://bugs.webkit.org/show_bug.cgi?id=230377
+                        considerBarrier(child1);
</ins><span class="cx">                     break;
</span><span class="cx">                 }
</span><span class="cx">                 case Array::Contiguous:
</span><span class="lines">@@ -277,7 +277,8 @@
</span><span class="cx">                 
</span><span class="cx">             case PutPrivateName: {
</span><span class="cx">                 if (!m_graph.m_slowPutByVal.contains(m_node) && (m_node->child1().useKind() == CellUse || m_node->child1().useKind() == KnownCellUse))
</span><del>-                    considerBarrier(m_node->child1(), m_node->child3());
</del><ins>+                    // FIXME: there are some cases where we can avoid a store barrier by considering the value https://bugs.webkit.org/show_bug.cgi?id=230377
+                    considerBarrier(m_node->child1());
</ins><span class="cx">                 break;
</span><span class="cx">             }
</span><span class="cx"> 
</span></span></pre>
</div>
</div>

</body>
</html>