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...
-Tom On Fri, Aug 29, 2014 at 1:29 PM, Thomas E Enebo <tom.en...@gmail.com> wrote: > Thomas, > > 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. > > -Tom > > > > On Fri, Aug 29, 2014 at 1:24 PM, Thomas Wuerthinger < > thomas.wuerthin...@oracle.com> wrote: > >> 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. >> >> 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. >> >> 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. >> >> Truffle indeed supports JITing C code on the fly. See Chris Seaton’s blog >> post on how this benefits native Ruby extensions a lot: >> http://www.chrisseaton.com/rubytruffle/pushing-pixels/. >> >> - thomas >> >> On 29 Aug 2014, at 19:28, Mark Roos <mr...@roos.com> wrote: >> >> Thomas stated >> A successful research project should ultimately also advance the >> state >> of the art of what is used in production. >> >> Thomas one of the reasons many of us are building on the JVM is to take >> advantage of the entire >> universe of Java code available. Truffle, to me at least, appears as a >> replacement for Java and the >> JVM not an addition. Nice if ones goal is to make a new Smalltalk, not >> so nice if one wants a >> Smalltalk DSL. >> >> It would be interesting if Truffle could be used to create JNI like >> method handles on the fly. Then >> I could do what I do today. Today I find hot spots, write them in C, >> call them with JNI. The problem is that >> JNI calls are not like hotspot jit code calls ( threads, safe point >> issues, heap access etc). I am hoping that >> the Panama project makes a JNI call more like an intrinsic. They I could >> use the LLVM jit to do the >> C part on the fly. Or actually it seems like Truffle could do this as >> well. So Truffle as an add on would >> be interesting, it just has not been presented as such. >> >> I think your research is very interesting. >> >> regards >> mark >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> > > > -- > blog: http://blog.enebo.com twitter: tom_enebo > mail: tom.en...@gmail.com > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
