[llvm-dev] Sulong

[Manuel Rigger via llvm-dev]

Hi Sanjoy,

this Sunday I held a presentation at FOSDEM where I explained Sulong using
function pointer call inlining. Yesterday, I uploaded the slides [1].

We use a form of "guarded devirtualization" as you expected. We do this
based on Abstract Syntax Tree (AST) node rewriting in the interpreter. We
use a direct call node that directly calls a function if it matches the
function that has been profiled before. If it doesn't, we either insert
another such direct call node or fall back to an indirect call based on
some threshold. Truffle then can perform the inlining on the AST level.
After Graal compiles the AST to machine code and when the speculation on
the target fails, a deoptimization handler transfers back to the
interpreter where the node rewrite is handled.

We thus do not instrument the writes, but implement a polymorphic function
pointer inlining cache at the call site.

Since polymorphic inline caches are also often used to implement other
languages, Truffle's domain specific language allows to express this logic
in only a few lines of code. You can have a look at the implementation in
com.oracle.truffle.llvm.LLVMCallNode$LLVMFunctionCallChain.

- Manuel

[1]
https://fosdem.org/2016/schedule/event/llvm_sulong/attachments/slides/1205/export/events/attachments/llvm_sulong/slides/1205/Sulong.pdf


2016-02-01 17:21 GMT+01:00 Sanjoy Das <sanjoy at playingwithpointers.com>:

> Manuel Rigger via llvm-dev wrote:
> > Hi everyone,
> >
> > we started a new open source project Sulong:
> https://github.com/graalvm/sulong.
> >
> > Sulong is a LLVM IR interpreter with JIT compilation running on top of
> the JVM.
> > By using the Truffle framework, it implements speculative optimizations
> such as inlining of function pointer calls
> > through AST rewriting.
>
> I'm interested in hearing more about how you do this.  Do you use
> guarded devirtualization (i.e. `if *fn_ptr_loc != @foo then
> side_exit(); else @foo()`), or is there something else?  I'd guess
> implementing "invalidation" based deoptimization (i.e. the value of
> `fn_ptr_loc` changed, so deoptimize compiles that depend on it not
> changing) will require instrumenting all (?) writes that could alias
> `*fp_ptr_loc`?
>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160202/9884c8ff/attachment.html>