The Great Startup Problem

Thomas E Enebo tom.enebo at
Fri Aug 29 18:29:10 UTC 2014


  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.


On Fri, Aug 29, 2014 at 1:24 PM, Thomas Wuerthinger <
thomas.wuerthinger at> 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:
> - thomas
> On 29 Aug 2014, at 19:28, Mark Roos <mroos at> 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 at
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at

blog:       twitter: tom_enebo
mail: tom.enebo at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the mlvm-dev mailing list