3 ms·

Graal dev here. If you want to checkout all the sources/licenses of GraalVM CE. They are here: Graal: https://github.com/oracle/graal https://github.com/oracle

Graal dev here. If you want to checkout all the sources/licenses of GraalVM CE. They are here: Graal: https://github.com/oracle/graal https://github.com/oracle/graal (GPLv2 with CPE) JavaScript with Node Integration: https://github.com/graalvm/graaljs https://github.com/graalvm/graaljs (UPL - BSD license) Ruby: https://github.com/oracle/truffleruby https://github.com/oracle/truffleruby (EPL, GPLv2, LGPL) R: https://github.com/oracle/fastr https://github.com/oracle/fastr (GPLv2) Python: https://github.com/graalvm/graalpython https://github.com/graalvm/graalpython (UPL - BSD license) LLVM/Sulong: https://github.com/graalvm/sulong https://github.com/graalvm/sulong

leoh 8y ago
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.
- chrisseaton 8y ago
  > if I built an application with truffleruby, could I distribute it as a JAR Yes there is a Java embedding API. http://www.graalvm.org/docs/graalvm-as-a-platform/embed/ 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/jruby-java-interop.md https://github.com/oracle/truffleruby/blob/master/doc/user/j... Our own interop: https://github.com/oracle/truffleruby/blob/master/doc/user/polyglot.md https://github.com/oracle/truffleruby/blob/master/doc/user/p... > Having some difficulty finding documentation around this. https://github.com/oracle/truffleruby/tree/master/doc https://github.com/oracle/truffleruby/tree/master/doc
  - aardvark179 8y ago
    Be warned, the jruby compatible interop isn’t complete, and I don’t have the jruby test suite running for it because that requires a much more complete implementation to run at all. It’s good for quite a lot though.
  - sandGorgon 8y ago
    Actually, can you create a Graal/Truffleruby 101 example where a Ruby application is compiled to native and run ?
    - chrisseaton 8y ago
      It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application. 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.
      - sandGorgon 8y ago
        Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program? Will this be the case for truffle python, js,etc ?
        peoplewindow 8y ago
        I'm not on the Graal team but I can take a crack at an answer - it's because as languages get more dynamic, static ahead of time compilation becomes less and less effective and can even be counterproductive. To compile a Ruby program it really needs to be just-in-time compiled, or at least a partial ahead of time compile using injected profiling runs. 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.
        miguro 8y ago
        That's partly true, but depends on the particular program. There are Ruby programs that could be compiled ahead-of-time quite efficiently, despite their dynamic features. 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.
- grashalm 8y ago
  Yes you will be. But we use a different interface. Checkout this guide: http://www.graalvm.org/docs/reference-manual/polyglot/ http://www.graalvm.org/docs/reference-manual/polyglot/ 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.
  - aardvark179 8y ago
    We do have a partial implementation of the jruby API, though I don’t believe it works on substratevm due to reflection.
aidenn0 8y ago
Can GraalVM target the browser?
- chrisseaton 8y ago
  We did have a proof of concept JavaScript backend in the past but it’s never been public.
jerven 8y ago
I am so super happy about the graaljs license choice ! Thank you so much!
- ksec 8y ago
  This is actually the first time I heard of UPL, which from what i read in the FAQ [1] is basically a GPL v2 compatible Apache 2 license. Which was one of the problem Apple had with LLVM i think. I wonder why Apple decide not to use UPL? [1] https://oss.oracle.com/licenses/upl/#_What_is_the_1 https://oss.oracle.com/licenses/upl/#_What_is_the_1
jhawk28 8y ago
Is there a way to create a native binary using a main within jar and it's dependencies?
- chrisseaton 8y ago
  Yes just run `native-image -jar foo.jar`.
rraghur 8y ago
How would I go about creating a native image for a gem I've installed? I can't seem to find the documentation for this. Or have I misunderstood this totally? I thought I could do something like ruby script -> graal ruby --> jvm bytecode --> native image Update:: Doesn't look like I read it wrong - from this reddit comment[1] from 3months ago Ahh, I think there's some confusion here. What we do with the SVM is ahead of time compile the TruffleRuby interpreter, not an application. This is akin to what you'd do with MRI. Instead of treating Java as a language you compile to a .class file and load with the JVM, the SVM's native image generator compiles it to a native binary. There's likely no reason we couldn't compile Ruby applications into a static binary. I would also love to be able to distribute a ruby binary as a single statically compiled executable. Any pointers/directions? [1] https://www.reddit.com/r/ruby/comments/7o3wy9/graals_substrate_vm_is_now_open_source_what_does/ds9hnjv/ https://www.reddit.com/r/ruby/comments/7o3wy9/graals_substra...
- chrisseaton 8y ago
  > There's likely no reason we couldn't compile Ruby applications into a static binary. I think this was a theoretical observation. What is more likely in the near future is to be able to initialise your Ruby gem at compile time, so when you start your application it is already required and you can start execution as if all your require statements had already run.
sandGorgon 8y ago
>GraalVM is available as Community Edition (CE) and Enterprise Edition (EE). The current release is based on JDK 8. Why is this ? We are currently on JDK 10. Also - why is there no official Graal Python ?
- chrisseaton 8y ago
  I think Java 8 is the current LTS release isn’t it? Graal needs a stable platform to build on. And there is an official Python alongside the other languages.
truth_seeker 8y ago
Can it also target bytecode or .jar artefacts, this way all JVM languages which compiles into JVM bytecode can be benefited
- mike_hearn 8y ago
  Yes, GraalVM is built on HotSpot so it can run all bytecode languages too.
  - truth_seeker 8y ago
    Cool thanks. Keen to try it with Scala and Clojure. Curious to know, How effective would be it's JIT compared to HotSpot ? Any pointers ?
    - mike_hearn 8y ago
      There are research papers that discuss this. It depends a lot on the bytecode patterns. For Java it's usually as good as the current JITC unless you're relying heavily on auto vectorisation. For Scala it's about a 10% win on open source or a 20% win for enterprise Graal, according to Twitter at least. For Clojure I don't know. But from what I understand Clojure produces quite inefficient bytecode, so it may benefit a lot.
ericfrederich 8y ago
Why is this yet another implementation of Python? If C is supported why not use CPython itself?
- grashalm01 8y ago
  Because Graal.python will be a lot faster. Just running cpython on GraalVm is possible but does not get you anything.

leoh 8y ago

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.

chrisseaton 8y ago
> if I built an application with truffleruby, could I distribute it as a JAR Yes there is a Java embedding API. http://www.graalvm.org/docs/graalvm-as-a-platform/embed/ 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/jruby-java-interop.md https://github.com/oracle/truffleruby/blob/master/doc/user/j... Our own interop: https://github.com/oracle/truffleruby/blob/master/doc/user/polyglot.md https://github.com/oracle/truffleruby/blob/master/doc/user/p... > Having some difficulty finding documentation around this. https://github.com/oracle/truffleruby/tree/master/doc https://github.com/oracle/truffleruby/tree/master/doc
- aardvark179 8y ago
  Be warned, the jruby compatible interop isn’t complete, and I don’t have the jruby test suite running for it because that requires a much more complete implementation to run at all. It’s good for quite a lot though.
- sandGorgon 8y ago
  Actually, can you create a Graal/Truffleruby 101 example where a Ruby application is compiled to native and run ?
  - chrisseaton 8y ago
    It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application. 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.
    - sandGorgon 8y ago
      Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program? Will this be the case for truffle python, js,etc ?
      - peoplewindow 8y ago
        I'm not on the Graal team but I can take a crack at an answer - it's because as languages get more dynamic, static ahead of time compilation becomes less and less effective and can even be counterproductive. To compile a Ruby program it really needs to be just-in-time compiled, or at least a partial ahead of time compile using injected profiling runs. 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.
        miguro 8y ago
        That's partly true, but depends on the particular program. There are Ruby programs that could be compiled ahead-of-time quite efficiently, despite their dynamic features. 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.
grashalm 8y ago
Yes you will be. But we use a different interface. Checkout this guide: http://www.graalvm.org/docs/reference-manual/polyglot/ http://www.graalvm.org/docs/reference-manual/polyglot/ 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.
- aardvark179 8y ago
  We do have a partial implementation of the jruby API, though I don’t believe it works on substratevm due to reflection.

aidenn0 8y ago

Can GraalVM target the browser?

chrisseaton 8y ago
We did have a proof of concept JavaScript backend in the past but it’s never been public.

jerven 8y ago

I am so super happy about the graaljs license choice ! Thank you so much!

ksec 8y ago
This is actually the first time I heard of UPL, which from what i read in the FAQ [1] is basically a GPL v2 compatible Apache 2 license. Which was one of the problem Apple had with LLVM i think. I wonder why Apple decide not to use UPL? [1] https://oss.oracle.com/licenses/upl/#_What_is_the_1 https://oss.oracle.com/licenses/upl/#_What_is_the_1

jhawk28 8y ago

Is there a way to create a native binary using a main within jar and it's dependencies?

chrisseaton 8y ago
Yes just run `native-image -jar foo.jar`.

rraghur 8y ago

How would I go about creating a native image for a gem I've installed? I can't seem to find the documentation for this. Or have I misunderstood this totally? I thought I could do something like ruby script -> graal ruby --> jvm bytecode --> native image Update:: Doesn't look like I read it wrong - from this reddit comment[1] from 3months ago Ahh, I think there's some confusion here. What we do with the SVM is ahead of time compile the TruffleRuby interpreter, not an application. This is akin to what you'd do with MRI. Instead of treating Java as a language you compile to a .class file and load with the JVM, the SVM's native image generator compiles it to a native binary. There's likely no reason we couldn't compile Ruby applications into a static binary. I would also love to be able to distribute a ruby binary as a single statically compiled executable. Any pointers/directions? [1] https://www.reddit.com/r/ruby/comments/7o3wy9/graals_substrate_vm_is_now_open_source_what_does/ds9hnjv/ https://www.reddit.com/r/ruby/comments/7o3wy9/graals_substra...

chrisseaton 8y ago
> There's likely no reason we couldn't compile Ruby applications into a static binary. I think this was a theoretical observation. What is more likely in the near future is to be able to initialise your Ruby gem at compile time, so when you start your application it is already required and you can start execution as if all your require statements had already run.

sandGorgon 8y ago

>GraalVM is available as Community Edition (CE) and Enterprise Edition (EE). The current release is based on JDK 8. Why is this ? We are currently on JDK 10. Also - why is there no official Graal Python ?

chrisseaton 8y ago
I think Java 8 is the current LTS release isn’t it? Graal needs a stable platform to build on. And there is an official Python alongside the other languages.

truth_seeker 8y ago

Can it also target bytecode or .jar artefacts, this way all JVM languages which compiles into JVM bytecode can be benefited

mike_hearn 8y ago
Yes, GraalVM is built on HotSpot so it can run all bytecode languages too.
- truth_seeker 8y ago
  Cool thanks. Keen to try it with Scala and Clojure. Curious to know, How effective would be it's JIT compared to HotSpot ? Any pointers ?
  - mike_hearn 8y ago
    There are research papers that discuss this. It depends a lot on the bytecode patterns. For Java it's usually as good as the current JITC unless you're relying heavily on auto vectorisation. For Scala it's about a 10% win on open source or a 20% win for enterprise Graal, according to Twitter at least. For Clojure I don't know. But from what I understand Clojure produces quite inefficient bytecode, so it may benefit a lot.

ericfrederich 8y ago

Why is this yet another implementation of Python? If C is supported why not use CPython itself?

grashalm01 8y ago
Because Graal.python will be a lot faster. Just running cpython on GraalVm is possible but does not get you anything.