<div dir="ltr"><div>I think I said two things at the same time and I apologize.  I am interested in startup time and also warmup time.  Eventual performance looks great on Chris's blogs...<br><br></div>-Tom<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Aug 29, 2014 at 1:29 PM, Thomas E Enebo <span dir="ltr"><<a href="mailto:tom.enebo@gmail.com" target="_blank">tom.enebo@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"><div><div>Thomas,<br><br></div>  I am very excited about RubyTruffle and Truffle/Graal in general but to date I have never seen any numbers based on startup time?  From what I have gleamed startup time is not a fundamental design goal currently.  I have heard that some of these great numbers take many minutes to warm up.  Is there any data on this?  In my mind it sounds like Truffle today might actually warm up slower than invokedynamic.  Any clarification on this would be great.<br>

<br></div><div>-Tom<br><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Fri, Aug 29, 2014 at 1:24 PM, Thomas Wuerthinger <span dir="ltr"><<a href="mailto:thomas.wuerthinger@oracle.com" target="_blank">thomas.wuerthinger@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"><div>Thanks for your comment, Mark. Truffle is not at all meant as a replacement for Java or the JVM. We fully rely on regular and unmodified Java bytecodes for the definition of the Truffle guest language interpreters and on regular Java objects for the Truffle guest language object model. We support full Java interoperability. Think of it as nodes consisting of statically defined Java bytecodes that call each other. There are *no* runtime changes in HotSpot necessary - which is a fairly objective indicator that Truffle is arguably *closer* to the JVM as originally architected than invokedynamic, which needed so far a significant amount of HotSpot runtime changes with further runtime changes currently under discussion.</div>

<div><br></div><div>It is also not the case that Truffle and invokedynamic would be incompatible. You can use method handles and the invokedynamic bytecode like in every other Java program when defining your Truffle interpreters.</div>

<div><br></div><div>I would really be looking forward to hear solid technical arguments on why Truffle would somehow be such a dramatic architectural change to the JVM ecosystem. It is admittedly a change in thinking, because it demonstrates that the JVM functionality can be significantly enhanced without introducing new bytecode definitions.</div>

<div><br></div><div>Truffle indeed supports JITing C code on the fly. See Chris Seaton’s blog post on how this benefits native Ruby extensions a lot: <a href="http://www.chrisseaton.com/rubytruffle/pushing-pixels/" target="_blank">http://www.chrisseaton.com/rubytruffle/pushing-pixels/</a>. </div>

<span><font color="#888888"><div><br></div><div>- thomas</div><br></font></span><div><div><div><div>On 29 Aug 2014, at 19:28, Mark Roos <<a href="mailto:mroos@roos.com" target="_blank">mroos@roos.com</a>> wrote:</div>

<br></div></div><blockquote type="cite"><div><div><font face="sans-serif">Thomas stated</font>
<br><font size="3">        A successful research
project should ultimately also advance the state </font>
<br><font size="3">        of the art of what
is used in production.</font>
<br>
<br><font face="sans-serif">Thomas one of the reasons many of us
are building on the JVM is to take advantage of the entire</font>
<br><font face="sans-serif">universe of Java code available.  Truffle,
to me at least, appears as a replacement for Java and the</font>
<br><font face="sans-serif">JVM not an addition.  Nice if ones
goal is to make a new Smalltalk,  not so nice if one wants a</font>
<br><font face="sans-serif">Smalltalk DSL.</font>
<br>
<br><font face="sans-serif">It would be interesting if Truffle could
be used to create JNI like method handles on the fly.  Then</font>
<br><font face="sans-serif">I could do what I do today.  Today
I find hot spots, write them in C, call them with JNI.  The problem
is that </font>
<br><font face="sans-serif">JNI calls are not like hotspot jit code
calls ( threads, safe point issues, heap access etc).  I am hoping
that</font>
<br><font face="sans-serif">the Panama project makes a JNI call
more like an intrinsic.  They I could use the LLVM jit to do the</font>
<br><font face="sans-serif">C  part on the fly.  Or actually
it seems like Truffle could do this as well.  So Truffle as an add
on would</font>
<br><font face="sans-serif">be interesting,  it just has not
been presented as such.</font>
<br>
<br><font face="sans-serif">I think your research is very interesting.
 </font>
<br>
<br><font face="sans-serif">regards</font>
<br><font face="sans-serif">mark</font>
<br>
<br></div></div><div>_______________________________________________<br>mlvm-dev mailing list<br><a href="mailto:mlvm-dev@openjdk.java.net" target="_blank">mlvm-dev@openjdk.java.net</a><br><a href="http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev</a><br>

</div></blockquote></div><br></div><br>_______________________________________________<br>
mlvm-dev mailing list<br>
<a href="mailto:mlvm-dev@openjdk.java.net" target="_blank">mlvm-dev@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev</a><br>
<br></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>blog: <a href="http://blog.enebo.com" target="_blank">http://blog.enebo.com</a>       twitter: tom_enebo<br>mail: <a href="mailto:tom.enebo@gmail.com" target="_blank">tom.enebo@gmail.com</a>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>blog: <a href="http://blog.enebo.com">http://blog.enebo.com</a>       twitter: tom_enebo<br>mail: <a href="mailto:tom.enebo@gmail.com">tom.enebo@gmail.com</a>
</div>