Re: Truffle and mlvm

Benoit, Always a pleasure working with you :) If you have any questions or need assistance you can IM me or talk on #jruby on irc. Concurrency in Ruby+Truffle is a pretty big missing item; so it will be great to see this implemented. -Tom On Thu, Oct 2, 2014 at 7:26 AM, Benoit Daloze wrote:

Re: Truffle and mlvm

Welcome to the team of compiler wizardry students at JKU Linz! Reading through all the productisation concerns and adoption issues in this thread is probably not a good starting point for your PhD. Thinking primarily about opportunities and blinding out problems is the only way to make larger st

Re: Truffle and mlvm

Congrats on the fun gig, Benoit! Your goals sound like good ones. If there's potential to get lightweight coroutines, that could be a huge advantage for the truffle approach. We are also interested in pushing harder to share more impl between RubyTruffle and JRuby. This may mean pulling common co

Re: Truffle and mlvm

Hello Charles and Thomas, On 31 August 2014 00:04, Thomas Wuerthinger wrote: > Thanks a lot, Charlie, for this very detailed feedback! In fact, this is > probably the most comprehensive feedback we’ve received for Truffle so far > :). > > There are some valid points, some points where I’d like t

Re: Truffle and mlvm

On 09/05/2014 11:41 AM, Ali Ebrahimi wrote: Hi, On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax > wrote: I think that in term of concepts there is a kind of convergence between the couples Graal/Truffle and c2/java.lang.invoke. The force of Graal is to be ab

Re: Truffle and mlvm

Hi, On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax wrote: > I think that in term of concepts there is a kind of convergence between > the couples Graal/Truffle and c2/java.lang.invoke. > > The force of Graal is to be able to do partial evaluation directed user > code or by annotations, for me, Hot

Re: Truffle and mlvm

I think that in term of concepts there is a kind of convergence between the couples Graal/Truffle and c2/java.lang.invoke. The force of Graal is to be able to do partial evaluation directed user code or by annotations, for me, Hotspot is moving in that direction too, it already has special ann

Re: Truffle and mlvm

Thomas, Thanks I did read Chris' note and it sounds promising. Is there some reading on this? regards mark p.s. I am still wondering why Ruby was the target, not why there was a target.___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.op

Re: Truffle and mlvm

Mark, Yes, I understand that changes always bring both technical challenges and unfortunately as you mention also political ones. Truffle offers an incremental option (see details in Chris’ mail). It in particular also works exactly like you describe below: It is a Java library that makes execu

Re: Truffle and mlvm

Why JRuby+Truffle doesn't use the existing JRuby core classes: There's no fundamental reason why we couldn't have implemented JRuby+Truffle using the existing JRuby classes instead of writing our own. Perhaps we should have also tried just replacing the AST and using the existing core classes. T

Re: Truffle and mlvm

Mark, The reasons for the various projects building language implementations on top of Truffle (Ruby, JavaScript, Python, R, Smalltalk) are very similar to the motivations behind other language projects on top of the JVM like Jython, JRuby, or your own project of implementing a Smalltalk for th

Re: Truffle and mlvm

--PURE OPINION--- Thomas you state: Overall, I still believe that sometimes a larger step is needed when current techniques start to reach local maxima. Which, as you mention in other posts, only time will tell if your beliefs are correct. I have learned that when proposing suc

Re: Truffle and mlvm

Thomas You state ...a new language implementation platform. and then I strongly believe that Truffle is the best currently available vehicle to make Ruby competitive in terms of performance with node.js. If the goal is to create a 'new language' platform then why not c

Re: Truffle and mlvm

Jochen, While it is possible to build such a backend for backwards compatibility, we have not yet done so. Truffle AST interpreters can run on Android. They run several factors faster than regular AST interpreters as the rewriting and type-specialisation helps significantly (see Figure 13 in [1

Re: Truffle and mlvm

Thanks a lot, Charlie, for this very detailed feedback! In fact, this is probably the most comprehensive feedback we’ve received for Truffle so far :). There are some valid points, some points where I’d like to add a comment, and some where Graal and Truffle may have been misunderstood. I’ll try

Re: Truffle and mlvm

Am 30.08.2014 14:20, schrieb Thomas Wuerthinger: [...] Regarding environments supported by Truffle: Truffle interpreters are regular Java programs and therefore run on any JVM. For backwards compatibility, it is possible to build a Truffle backend that automatically generates bytecodes. can you

Re: Truffle and mlvm

Removing all context, so it's clear this is just my opinions and thoughts... As most of you know, we've opened up our codebase and incorporated the graciously-donated RubyTruffle directly into JRuby. It's available on JRuby master and we are planning to ship Truffle support with JRuby 9000, our ne

Re: Truffle and mlvm

Jochen, Yes, interpreter based languages are easier to migrate. It is possible to simulate invokedynamic and the method handle chain with Truffle trees. Unfortunately, I do not expect this to mitigate the issues of the invokedynamic architecture that people have been discussing here. The best t

Re: Truffle and mlvm

Thomas, for me the most easy target for truffle are interpreter based languages. What would be really nice is to have some kind of migration tutorial, which shows the steps involving the transformation of a bytecode producing runtime to truffle. Almost all language implementors using invoke

Re: Truffle and mlvm

Mark, It is possible to use Truffle for parts of the functionality of your language while the language itself is implemented with a bytecode generation approach (e.g., native extensions or regular expressions). Overall, I still believe that sometimes a larger step is needed when current techniq

Truffle and mlvm

Moving from the startup thread. Thomas has been wondering why using Truffle as a solution is not getting immediate traction. I was initially, and continue to be, quite interested in Truffle. So how could Truffle help out us non Java on the JVM developers to the point where we could be a drivi