The Great Startup Problem

Thomas E Enebo tom.enebo at gmail.com
Fri Aug 29 18:33:27 UTC 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140829/1cce326a/attachment.html>


More information about the mlvm-dev mailing list