Truffle and mlvm

[Ali Ebrahimi]

Hi,


On Fri, Sep 5, 2014 at 1:47 PM, Remi Forax <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?

Ali Ebrahimi

Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140905/10d9774f/attachment-0001.html>