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> 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 > 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
