<div dir="ltr">Thanks John.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:17.0001010894775px;background-color:rgb(240,240,240)">A switch should not be measured by the raw size of the instruction.<br></span><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:17.0001010894775px;background-color:rgb(240,240,240)">If several adjacent keys branch to the same successor, surely that should count as a single test and branch.</span></blockquote><div><br></div><div>Although the adjacent keys branching to same successor is yet another case, it seems like any switch (whether it has adjacent keys or not) that gets lowered to a jump table should be *heavily* discounted by whatever heuristic is used.  If the JIT were to incorporate profile info and detect common targets, then even better :).</div><div><br></div><div>Thanks guys.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 5, 2015 at 1:02 PM, John Rose <span dir="ltr"><<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Bug updated; thanks!<div><div class="h5"><div><br><div><blockquote type="cite"><div>On Jun 5, 2015, at 9:04 AM, Vitaly Davidovich <<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Right, I didn't see FreqInlineSize on there, and the large jump table scenario seemed like one worth calling out as well?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 5, 2015 at 12:03 PM, Roland Westrelin <span dir="ltr"><<a href="mailto:roland.westrelin@oracle.com" target="_blank">roland.westrelin@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> By "handled better" I mean for the JIT to not get scared about the bytecode size since machine code is rather compact and quick to execute (especially if the indirect jump via the jump table is predicted well).  This is somewhat analogous to the JIT being spooked by methods > MaxInlineSize where the actual bytecode size isn't representative of the real cost (e.g. dead code, asserts, etc), but for FreqInlineSize.<br>
<br>
</span>John suggested a way to improve our heuristics:<br>
<br>
<a href="https://bugs.openjdk.java.net/browse/JDK-6316156?focusedCommentId=13443564&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13443564" target="_blank">https://bugs.openjdk.java.net/browse/JDK-6316156?focusedCommentId=13443564&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13443564</a><br>
<span><font color="#888888"><br>
Roland.</font></span></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>