The Great Startup Problem

Fri Aug 29 19:31:54 UTC 2014

Truffle is an architecture based on AST interpreters. This means that immediate startup is as fast as it can get to load an AST interpreter written in Java into your VM and start executing it. Obviously, this heavily depends on fine engineering of the guest language runtime and interpreter (i.e., perform as much work lazy as possible), but has architectural advantages over a solution that needs to load a Java bytecode generator into the VM and load dynamically generated Java bytecodes before it can execute the first line of guest language code (in the Java interpreter). More importantly, if you support AOT for Java and use it for the AST interpreter and respectively the Java bytecode generator, the performance gap widens.

Warmup depends heavily on the speed of the JIT. In the current system, our JIT is written in Java and has therefore the architectural disadvantage that it needs to warmup as well. If AOT is available, this disadvantage disappears. There is no significant additional complication for the JIT when compiling Truffle trees compared to compiling method handle trees.

We will work on a comparison between JRuby with invokedynamic and JRuby using Truffle to show startup/warmup curves.

We have a separate research project at Oracle Labs called “SubstrateVM” that explores a low footprint and low startup option for Truffle guest language interpreters via AOT. It brings startup into the 10ms range and makes it therefore competitive with native VMs such as MRI or V8. Compared to Graal/Truffle, it is however in a far less complete state. We still think that this is going to be an interesting opportunity on the long run.

Btw, we will have a workshop on virtual machines at ETH Zurich on 11th and 12th of September where we will discuss compilation technologies. Anybody who is interested to join, please send me a private message.

- thomas

On 29 Aug 2014, at 20:33, Thomas E Enebo <tom.enebo at gmail.com> wrote:

> 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.enebo at 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.wuerthinger at 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 <mroos at 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 at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> 
> 
> 
> -- 
> blog: http://blog.enebo.com       twitter: tom_enebo
> mail: tom.enebo at gmail.com
> 
> 
> 
> -- 
> blog: http://blog.enebo.com       twitter: tom_enebo
> mail: tom.enebo at gmail.com
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140829/2b906be7/attachment.html>