Truffle and mlvm

[Remi Forax]

On 09/05/2014 11:41 AM, Ali Ebrahimi wrote:
> Hi,
>
>
> On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at 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?

The code pushed in the valhalla workspace uses bytecode generation (with 
ASM) to do the type specialization.
I propose to use the same bytecode and to do the specialization either 
in the bytecode parser (in that case
the code can run with an unmodified interpreter) or at JIT time (if 
either there is no interpreter or
if there is a modified interpreter that use an indirection mechanism or 
a double stack representation).

>
> Ali Ebrahimi

Rémi

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