Truffle and mlvm

Fri Sep 5 09:17:51 UTC 2014

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 annotations like @Stable or @ForceInline, and 
ultimately the method handle implementation will use exactly the same 
tricks (like read/write access to hotspot internal data-structure or 
magical deoptimization method [1] by example) that Truffle uses.

For me, the major difference is that there is no clear way to do type 
specialization in the invokedynamic world, each runtime implementation 
has to come with it's own solution (or not !) while Truffle has 
TruffleSOM (even if I'm not a fan of the approach of TruffleSOM, it 
exists). A way to close the gap, is to use a library on top of ASM that 
does type specialization (and profiling) and delegate to invokedynamic 
the semantics of the language (It was the main idea of the talk I've 
submitted to the JVM Summit this year).

I think that it's not a good idea to let people to directly use tools 
that do partial evaluation. The problem of partial evaluation is that 
it's very easy to introduce major regressions because one thing is not 
in line with respect to all the others, it's too magic. But I believe 
that it's a good way to solve the problem we currently have with the 
implementation of method handles in Hotspot.

I really would like to have an API that relieve runtime developers to 
take care about type specialization.
That's why I think that type specialization should not be done outside 
the VM as currently said, but inside the VM.
To be crystal clear, runtimes should generate code that instead of using 
iload, lload, dload, etc. use only one bytecode op vload (v for virtual 
and not v for value), and we should provide a way to instantiate 
different methods from a generic bytecode by providing type informations 
(signature of the specialized method + return type of each calls is 
enough), a kind of defineAnonymousClass on steroid.
Given that instruction like vload are needed to support value type, the 
idea is to extend it to support primitive type too and later to allow to 
specify type information along the bytecodes. This will allow to write 
one code and to create multiple specialized version of the same code 
without neither generating a bunch of bytecodes (like we do now) nor 
relying on partial evaluation + code generation (like TruffleSOM does).

Rémi

[1] http://cr.openjdk.java.net/~vlivanov/profiling/

On 08/31/2014 04:12 PM, Thomas Wuerthinger wrote:
> 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]). They come with an 
> annotation-based DSL that makes writing specialisations easier (see 
> Figure 9 in [2]).
>
> I believe it is technically possible to also support the partial 
> evaluation (and therefore high performance) on Android, but whether 
> this might happen is a question more to ask the Android community or 
> Google. I am not aware that JRuby with invokedynamic or Nashorn would 
> run on Android. If so, I would be interested to see the performance 
> numbers. From experiences of porting Groovy to Android [3]: "It should 
> be known that using dynamic code should be limited to non CPU 
> intensive parts of the application, since it involves reflection."
>
> It is possible to gradually use Truffle only for specific parts (e.g., 
> regular expressions, FFI, only for performance-critical guest language 
> methods). Within one guest language method, it is however not 
> beneficial to mix Truffle with bytecode generation, because it 
> increases complexity and will not provide you the main benefits.
>
> - thomas
>
> [1] 
> http://lafo.ssw.uni-linz.ac.at/papers/2012_DLS_SelfOptimizingASTInterpreters.pdf
> [2] http://lafo.ssw.uni-linz.ac.at/papers/2014_GPCE_TruffleDSL.pdf
> [3] http://www.infoq.com/news/2014/06/groovy-android
>
> On 30 Aug 2014, at 22:36, Jochen Theodorou <blackdrag at gmx.org 
> <mailto:blackdrag at gmx.org>> wrote:
>
>> 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 point me to some documentation for that bytecode generation 
>> backend? Also... can I make a something with truffle that will run on 
>> android? Not exactly a JVM, I know.
>>
>>> 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.
>>
>> sure, the problem is more if you can do this change gradual or if you 
>> have to do it all at once. For example, if you could still write your 
>> bytecode and choose to only replace some method calls with truffle 
>> parts, that would help very much
>>
>>> 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.
>>
>> I really really hope that I didn't say anything that sounded like 
>> that. If somebody understood it like that, then I appologize. That 
>> was not intended. It's just new.
>>
>> bye Jochen
>>
>>
>> -- 
>> 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 <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

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