<!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>[243088] 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/243088">243088</a></dd>
<dt>Author</dt> <dd>rmorisset@apple.com</dd>
<dt>Date</dt> <dd>2019-03-18 12:03:32 -0700 (Mon, 18 Mar 2019)</dd>
</dl>

<h3>Log Message</h3>
<pre>Remove the inline capacity of Operands
https://bugs.webkit.org/show_bug.cgi?id=195898

Reviewed by Yusuke Suzuki.

Operands currently has a vector with an inline capacity of 24.
I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.

So I removed the inline capacity of the vector in Operands, and here are the results:
Baseline Jetstream2:
159.741
159.746
159.989
Baseline RAMification on grouped and jit tests: (end/peak/score)
89.288/89.763/89.526
90.166/90.761/90.418
89.560/90.014/89.787
After optimization Jetstream2:
159.342
161.812
162.037
After optimization RAMification:
89.147/89.644/89.395
89.102.89.585/89.343
88.953/89.536/89.2444

So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
I hope to land this, and get more accurate results from the bots.

* bytecode/Operands.h:</pre>

<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceJavaScriptCoreChangeLog">trunk/Source/JavaScriptCore/ChangeLog</a></li>
<li><a href="#trunkSourceJavaScriptCorebytecodeOperandsh">trunk/Source/JavaScriptCore/bytecode/Operands.h</a></li>
</ul>

</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourceJavaScriptCoreChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/ChangeLog (243087 => 243088)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/ChangeLog    2019-03-18 18:47:43 UTC (rev 243087)
+++ trunk/Source/JavaScriptCore/ChangeLog       2019-03-18 19:03:32 UTC (rev 243088)
</span><span class="lines">@@ -1,3 +1,38 @@
</span><ins>+2019-03-18  Robin Morisset  <rmorisset@apple.com>
+
+        Remove the inline capacity of Operands
+        https://bugs.webkit.org/show_bug.cgi?id=195898
+
+        Reviewed by Yusuke Suzuki.
+
+        Operands currently has a vector with an inline capacity of 24.
+        I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
+        This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
+        Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
+        
+        So I removed the inline capacity of the vector in Operands, and here are the results:
+        Baseline Jetstream2:
+        159.741
+        159.746
+        159.989
+        Baseline RAMification on grouped and jit tests: (end/peak/score)
+        89.288/89.763/89.526
+        90.166/90.761/90.418
+        89.560/90.014/89.787
+        After optimization Jetstream2:
+        159.342
+        161.812
+        162.037
+        After optimization RAMification:
+        89.147/89.644/89.395
+        89.102.89.585/89.343
+        88.953/89.536/89.2444
+        
+        So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
+        I hope to land this, and get more accurate results from the bots.
+
+        * bytecode/Operands.h:
+
</ins><span class="cx"> 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
</span><span class="cx"> 
</span><span class="cx">         [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
</span></span></pre></div>
<a id="trunkSourceJavaScriptCorebytecodeOperandsh"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/bytecode/Operands.h (243087 => 243088)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/bytecode/Operands.h  2019-03-18 18:47:43 UTC (rev 243087)
+++ trunk/Source/JavaScriptCore/bytecode/Operands.h     2019-03-18 19:03:32 UTC (rev 243088)
</span><span class="lines">@@ -266,7 +266,7 @@
</span><span class="cx">     
</span><span class="cx"> private:
</span><span class="cx">     // The first m_numArguments of m_values are arguments, the rest are locals.
</span><del>-    Vector<T, 24, UnsafeVectorOverflow> m_values;
</del><ins>+    Vector<T, 0, UnsafeVectorOverflow> m_values;
</ins><span class="cx">     unsigned m_numArguments;
</span><span class="cx"> };
</span><span class="cx"> 
</span></span></pre>
</div>
</div>

</body>
</html>