Hi,
On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax <fo...@univ-mlv.fr> 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, 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). > > How this relate to Project Valhalla's Type Specialization effort? Ali Ebrahimi Rémi >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
