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 <blackd...@gmx.org
<mailto:blackd...@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@openjdk.java.net <mailto:mlvm-dev@openjdk.java.net>
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
