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. One area of our research is to provide alternative ways of executing LLVM bitcode that provide memory safety guarantees. We are looking forward to feedback and/or contributions! - Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160130/0c6f46c0/attachment.html>
Am 30.01.2016 um 23:35 schrieb Manuel Rigger via llvm-dev:> We are looking forward to feedback and/or contributions!What's the primary target audience for the project? It could be people who want to take their JVM bytecode to machine code, or it could be people who want to implement a compiler in Java but use LLVM for the backend, the Readme wouldn't tell me (probably because I don't know Truffle, or am missing other background). Regards, Jo
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
Hi Jo, I agree that the readme failed to explain for what Sulong can actually be used for. Based on your feedback, I updated it to also include some use cases. - Manuel 2016-01-31 0:01 GMT+01:00 Joachim Durchholz via llvm-dev < llvm-dev at lists.llvm.org>:> Am 30.01.2016 um 23:35 schrieb Manuel Rigger via llvm-dev: > >> We are looking forward to feedback and/or contributions! >> > > What's the primary target audience for the project? > It could be people who want to take their JVM bytecode to machine code, or > it could be people who want to implement a compiler in Java but use LLVM > for the backend, the Readme wouldn't tell me (probably because I don't know > Truffle, or am missing other background). > > Regards, > Jo > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160202/c5a4d0c9/attachment.html>
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>