Thanks! Out of curiosity — if I built an application with truffleruby, could I distribute it as a JAR (provided that it was run under JDK 9)? Are there ways to call out to Java like JRuby? Having some difficulty finding documentation around this.
Yes there is a Java embedding API.
http://www.graalvm.org/docs/graalvm-as-a-platform/embed/
> (provided that it was run under JDK 9)
It can run on 8. It'll be fast on JDK 9 or 10 because these have the interface to use Graal.
> Are there ways to call out to Java like JRuby?
JRuby compatible interop:
https://github.com/oracle/truffleruby/blob/master/doc/user/j...
Our own interop:
https://github.com/oracle/truffleruby/blob/master/doc/user/p...
> Having some difficulty finding documentation around this.
It’s good for quite a lot though.
It's a little bit more complex than that in that we can run a Ruby application ahead of time up to a certain point where we compile it, and then when you run the application that state when it was compiled is restored. So we load the core library during compilation for example.
Will this be the case for truffle python, js,etc ?
The problem is that the semantics of Ruby are such that you can't compile it efficiently out of the box. TruffleRuby can but only by making tons of assumptions at runtime that might not be valid. So it compiles code on the assumption your program is normal and not weird, and if those assumptions are violated, it goes back to interpreting the source code.
Therefore even if you could pre-compile Ruby in some pedantic sense, you'd still need the source code to fall back to when the JITC has to bail out.
The slow-path version of the code that violates runtime assumptions can still be compiled as an alternative variant - so instead of switching from fast compiled code to the interpreter, the code violating the assumptions can switch to slow-path compiled code.
Dir.glob("some dir/*").each do |filename|
require filename
end
But other times it is used as a plugin mechanism, where the expectation is for the code to be provided by a user or other developer, and processing this statically at compile time would remove capabilities that the user would expect.
You can't automatically determine things like that, because it is down to developer intent and the code does not document the intent.
So the problem goes deeper than being about being able to revert to a slow path: To compile Ruby in a meaningful way you need to make some level of trade-off in what aspects of Ruby you decide to treat as "ahead of time" vs runtime, because there is no clear rule that says "now the program has been loaded; everything after this is runtime".
I would think that the fact that Ruby constructs that look like what would be compiler directives in a more static language (e.g., Ruby's “require” vs C’s “#include”) have their semantics defined in a way which both depends on and affects runtime state means that AOT compiling Ruby in the strict sense gets you very little, whereas running it to a certain point AOT and saving the runtime state gets you closer to what you'd expect from compiling based on usually-compiled languages.
Select your start and your target language and it will show you an example. Its a very basic example, but it basically works with all Java types. We will provide better docs soon.