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
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
