
Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM - gfredtech
https://github.com/graalvm/sulong
======
jchw
A few potential use cases:

\- Compile once, run anywhere for low-level languages like C++. With
limitations, of course.

\- More debugging capabilities. Maybe it could be used for dynamic analysis.
Theoretically it should be possible to change code at runtime.

\- Something like Valgrind? Valgrind is really complex and doesn't run on
Windows at all. It seems like you could make a portable substitute with this.

\- Maybe GraalVM can be used to provide additional memory safety guarantees,
not sure.

Kind of hard for me to say because I don't actually know exactly what GraalVM
provides, so it's kind of a guess. But it does seem like there are some
genuine use cases beyond the neatness of it.

~~~
noahdesu
I believe that one compelling use case is to avoid the overhead of cross
language boundaries (ie JNI) when the native code is compiled to bitcode and
run with Sulong.

~~~
__s
Previous Graal show offs had Ruby running C extensions by implementing a Graal
JIT for x86. I imagine LLVM a nicer level of abstraction to intercept at

This seems to imply only implementing a C JIT, so my memory may be wrong:
[http://chrisseaton.com/rubytruffle/cext](http://chrisseaton.com/rubytruffle/cext)

Truffleruby seems to be using Sulong now:
[https://github.com/oracle/truffleruby/commit/f16a52934437a96...](https://github.com/oracle/truffleruby/commit/f16a52934437a968bf2d2320ed56ce8910d52605)

------
ot
> Compiling without optimizations is not recommended with Sulong. In
> particular, cross-language interoperability with Java or another Truffle
> language will not work when the bitcode is compiled without optimizations.

This is _very_ weird. How can (lack of) optimizations possibly interfere with
things like calling conventions? Whatever they're doing, it smells of fragile.

------
ksec
On a related note, Sulong is what makes Nokogiri and OpenSSL possible on
TruffleRuby. This only happened two weeks ago, may be it is the reason why
Sulong is posted again to HN.

I am trying hard not to get overly excited, let see some real world benchmarks
once Truffle is ready to run Real World Rails.

------
1ris
How much faster/slower is it than aot code? I'm disapointed to see no
benchmarks.

~~~
rurban
It's in the papers. About 20% slower.

The main use case seems to be speed up dynamic languages (ruby, python,
javascript, R), and Sulong is used to handle the C extensions, so that the
optimizations can be performed across the language boundaries. Unboxing and
inlining mostly in the hot paths. Makes sense. Plus more memory safety than
C/C++/Fortran.

~~~
0xFFC
Sorry I couldn't find the paper in github page. Can you give a link?

~~~
rurban
There's a docs dir.
[https://github.com/graalvm/sulong/blob/master/docs/PUBLICATI...](https://github.com/graalvm/sulong/blob/master/docs/PUBLICATIONS.md)

------
anarazel
Hm. Cool work, but I'm not sure I really see a practical use case? Ideas
welcome.

~~~
chrisseaton
For example I use it to run Ruby's C extensions on the JVM.

------
gigatexal
Polyglotting and being able to run it on any platform is pretty cool

------
earenndil
I wonder if it would be possible to run other languages such as rust, d, or
ante, that use llvm, on this? Specifically interested in how languages with gc
like d or nim will fare.

~~~
peoplewindow
Rust runs. Look at the PR queue.

