So, many dynamic languages have a C API that allows you to write methods in C, and for those methods to do things to objects of the higher level language. This is normally a big optimisation boundary because you have to assume any value could have been altered during a C call. However if you run your C extensions through the same framework as you implement your hogh level language then you can remove that optimisation boundary entirely.

I believe it’s more about truffle’s llvm interpreter (which is perhaps the successor of this project), but one motivation is that many scripting languages (python, ruby) use C (and fortran) libraries extensively through FFI.

Truffle can give these scripting languages a huge boost in performance (TrufflyRuby is 3x faster than the second fastest implementation), but the JVM “doesn’t like to” rely on FFI all that much - and also, truffle is polyglot with the ability to optimize between different languages. So by creating an LLVM interpreter, ruby or python calling into that can be also optimized by e.g. inlining, in certain cases bettering the performance compared to native FFI.

Other than becoming truly cross-platform, running on top of a singular runtime gives it the ability to observe these parts as well (which in itself a huge advantage because the JVM has some killer observability tools), so for example project loom might be applicable to a python script using C libs for IO, putting the whole on a virtual thread and making its blocking calls unblocking magically.

I could be wrong, but can't Truffle languages freely interoperate within the JVM? (https://www.graalvm.org/22.0/reference-manual/polyglot-progr...)

As an interpreter, it could be very powerful for development, prototyping, and developing POCs.

Benefit of the JVM without the bloat of the Java language. I suspect particularly for resource constraint systems, RAM in particular. Not particularly convinced myself!

The equivalent of link time optimisation with Java, perhaps?

Mostly migration of legacy programs probably, so companies can say they ported their stuff to java. It's stupid but companies do it.