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