[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

Truffleruby seems to be using Sulong now: https://github.com/oracle/truffleruby/commit/f16a52934437a96...

[jchw]

I wonder if that's the point. I'm not sure, I was just making guesses myself since it doesn't seem the motivation is stated.

[anarazel]

LLVM IR usually is platform dependant. Especially so when generated by clang etc..

[jchw]

Obviously, you can't just run it through vanilla Clang and call it a day. However, you can do something like PNaCl where you treat the runtime environment as its own platform separate from the rest of the world with its own ABI. I'm sure some languages are more or less impacted as well, for C and C++ the problem is obvious because platforms vary so widely.