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
