<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 4:38 PM, Pierre Fenoll <span dir="ltr"><<a href="mailto:pierrefenoll@gmail.com" target="_blank">pierrefenoll@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is surely a very naive idea on how to one day get cross-module inlining<div>or at least enlarge the range of possibilities for the JIT.</div></div></blockquote></div><br></div><div class="gmail_extra">A JIT should be free to build up optimized code with full inlining as long as it knows how to deoptimize that code again should a new version of a module be loaded. One of the alluring thing of a JIT is that it is free to make dynamic choices in the running code without any priori knowledge. A traditional compiler which works on static data needs to operate on static analysis alone. This is usually easier if the program has less wiggle room of interpretation. And this is the case if you have a static type system...<br><br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>