Truffle and mlvm

Sat Aug 30 12:20:21 UTC 2014

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 tutorial for such a migration is to watch our ongoing efforts to make JRuby run with Truffle (https://github.com/jruby/jruby/wiki/Truffle). We are going to significantly increase our contributions to this open source project. This will also allow more meaningful comparisons in the future.

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.

Regarding the requirement for change: Yes, it is true that adapting to a new API requires changes. Changing the compiler and/or the interpreter is however happening regularly in larger language implementation projects (e.g., the new IR backend for JRuby). This change in the API is required, because it gives you the main advantage.

I do *not* believe that the problems with invokedynamic are due to a poor implementation by the HotSpot engineers. I also do *not* believe they are due to a poor job by the language implementors. They are due to the chosen API *between* HotSpot and language implementors.

- thomas

On 30 Aug 2014, at 09:32, Jochen Theodorou <blackdrag at gmx.org> wrote:

> 
> 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 invokedynamic should fall in this category, unless they have an interpreter ready as well. So the obvious target for that would be kind of an invokedynamic replacement.
> 
> But I strongly assume, that the strengths of truffle can't be played out like this. That's what it makes an implementation approach wall. And then there is the problem that you may have to support environments without truffle.
> 
> bye Jochen
> 
> 
> Am 30.08.2014 06:15, schrieb Thomas Wuerthinger:
>> 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 techniques start to reach local maxima.
>> 
>> Regards, thomas
>> 
>> On 29 Aug 2014, at 22:59, Mark Roos <mroos at roos.com
>> <mailto:mroos at roos.com>> wrote:
>> 
>>> 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
>>> driving force behind it.  First note that myself and I would guess all
>>> language implementers
>>> ( as compared to researchers ) are like Marcus, very pragmatic.  Small
>>> changes are welcome
>>> but wholesale ones are seen as a barrier.  So to use Truffle I would
>>> want to see it as an
>>> addition to the jvm which addresses one of my specific issues.
>>> 
>>> The issue that I have where the solution is not evident is in the
>>> creation of primitive
>>> methods.  A primitive method in Smalltalk takes the arguments and some
>>> constants
>>> and executes object code to deliver the result.  Traditionally written
>>> C or assembler
>>> I now use Java and JNI.  Since we have the equivalent to value types
>>> (wrapped byte[])
>>> primitives can be quite important for our vector math ops performance.
>>> 
>>> What would be very nice would be to attach a truffle.jar, pass it some
>>> data structure
>>> which defines a primitive and get back a method handle wrapping some
>>> optimized object code.
>>> Given that this MH comes from a known source perhaps the jni like
>>> overhead could
>>> be much reduced similar to an intrinsic.
>>> 
>>> This would be much simpler, I would guess, then the Panama effort to
>>> wrap arbitrary code.
>>> Plus I would not have to have a pre made object file per external
>>> environment.
>>> 
>>> regards
>>> mark_______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net <mailto: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
>> 
> 
> 
> -- 
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
> 
> _______________________________________________
> 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/20140830/2442a8a2/attachment-0001.html>