
GraalVM: Run Programs Faster Anywhere - nirvdrum
http://www.graalvm.org/
======
grashalm
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
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
> 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/j...](https://github.com/oracle/truffleruby/blob/master/doc/user/jruby-
java-interop.md)

Our own interop:

[https://github.com/oracle/truffleruby/blob/master/doc/user/p...](https://github.com/oracle/truffleruby/blob/master/doc/user/polyglot.md)

> Having some difficulty finding documentation around this.

[https://github.com/oracle/truffleruby/tree/master/doc](https://github.com/oracle/truffleruby/tree/master/doc)

~~~
sandGorgon
Actually, can you create a Graal/Truffleruby 101 example where a Ruby
application is compiled to native and run ?

~~~
chrisseaton
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
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
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
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.

~~~
vidarh
While that's true, and switching to a slower path solves many problems,
consider this common Ruby pattern:

    
    
        Dir.glob("some dir/*").each do |filename|
            require filename
        end
    

A _lot_ of Ruby code messes with how code is loaded (heck, "require" in almost
every Ruby install is not the built in "require" but one that has been
dynamically replaced). Sometimes that is intended to implement static
behavior: The expectation is that the code remains the same. It's just a way
of avoiding having to maintain a list manually.

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".

------
ruffrey
It sounds amazing. But Oracle's legal reputation means I can never safely
choose their tech stack, especially not something open source and free.

One of a million examples, this happens on the front page of HN at the same
time:

[https://www.reddit.com/r/javascript/comments/8d0bg2/oracle_o...](https://www.reddit.com/r/javascript/comments/8d0bg2/oracle_owns_javascript_so_apple_is_taking_down_my/)

~~~
rockostrich
Oracle can't sue you for using Java and OpenJDK.

------
saurik
I have been paying some scant attention to GraalVM for some time, having been
excited by "universal VMs" for decades now (including setups like LLVM, which
most people forget was designed as a JIT-compiled VM, despite that being in
the name), and I develop Cycript (which is somewhat the "opposite" technology,
binding together existing virtual machines all into the same process space and
doing crazy interop; though I haven't done a public release now in well over a
year).

I am excited to see such a beast coming from a major company with a strong
track record in VMs, and particularly given that it is based on their existing
JDK, and am particularly excited that it now seems to be available!

I have some questions that I did not managed to easily get answered from
looking over the website.

Can I AOT with this (via SubstrateVM) and deploy to "mobile" targets, and
specifically iOS?

Are there any examples of embedding GraalVM in an existing native application
(such as the noted idea of having GraalVM accessible inside of MySQL)?

Is there an existing embedding for node.js? (I don't mean "can I run node.js
apps on GraalVM?"; I mean: from node.js, can I instantiate a GraalVM and give
it code to execute in a new context, or will I need to build my own bindings
to the GraalVM embedding API for that first?)

I did find some documentation for using an embedded GraalVM in a Java
application, but while I work on many projects in many languages, none of them
have been written in Java now for over a decade. I guess I was expecting a
C/C++ API to be documented somewhere, not a Java API (due to the listed
prototypical embeddings, and based on my long experience with embedding other
virtual machines, including the Oracle/Sun JVM).

[http://www.graalvm.org/docs/graalvm-as-a-
platform/](http://www.graalvm.org/docs/graalvm-as-a-platform/)

~~~
mike_hearn
_Is there an existing embedding for node.js_

That's what their "node" program actually is. It's regular node but using
GraalVM instead of V8. The semantic difference you're getting at doesn't seem
to exist.

 _I guess I was expecting a C /C++ API to be documented somewhere, not a Java
API_

SubstrateVM has a C API that can be used to start it up that's not the same as
JNI, however, bear in mind Graal can be used as a plugin to regular HotSpot
too. So you can just embed the JVM the usual way and ship the Graal compiler
with it, enabled via a command line flag. So yes you can do this and it
doesn't require any new documentation.

~~~
saurik
> That's what their "node" program actually is. It's regular node but using
> GraalVM instead of V8. The semantic difference you're getting at doesn't
> seem to exist.

No, because what I'm trying to accomplish is "I'm inside of a node.js program
and I want to instantiate a GraalVM virtual machine instance context, load a
random Java class (or whatever), and run a function on that class". Even if
I'm running my node.js code on top of GraalVM, the semantic difference
fundamentally exists. Like, you are trying to tell me that somehow running my
node.js program on top of GraalVM is the same thing as being able to run
GraalVM from inside of my program (which just so happens to be written in
node.js, but that's arbitrary and meaningless in a way: I just want good
bindings for the language I happened to write it in) on arbitrary code, but
that clearly doesn't make any sense. I mean, it certainly isn't true for their
Java embedding API, why/how would it somehow be true for their node.js API?

> SubstrateVM has a C API that can be used to start it up that's not the same
> as JNI... So you can just embed the JVM the usual way and ship the Graal
> compiler with it...

But SubstrateVM is the offline VM for AOT use, not the runtime VM for JIT use,
so I really am not that interested in the SubstrateVM API... it isn't at all
relevant for the use case I'm describing for embedding GraalVM; and the Graal
compiler in this context is also for AOT use, which again isn't relevant for
the use case of embedding the GraalVM.

What makes GraalVM interesting here is that it is a JIT. Just take a step back
for a second and imagine you have a C program, and you want to boot that JIT
and use it, as a library, loaded into your process. That's the use case here.
You seem to be confusing that with either running the C program inside of the
VM (which doesn't even change the problem) and then later with pre-compiling
the thing we want to load and bringing the compiled code into the process
(which bypasses the wonderful goal of working with the JIT).

The way you do this using their Java embedding API is clearly documented, and
it is absolutely not the same thing as running a Java application in the
GraalVM: it is a set of APIs that let you instantiate Graal Context objects,
eval() code in various languages, and then work with the proxy Value objects.
I am asking if that API has been exposed to any languages other than Java yet.
It seems (from the answer from someone who actually works on Graal from 8
hours before your comment) that the answer is "yes" for C/C++, but I'm still
guessing the answer is "no" for node.js.

[http://www.graalvm.org/docs/graalvm-as-a-
platform/embed/](http://www.graalvm.org/docs/graalvm-as-a-platform/embed/)

~~~
mike_hearn
My point is that you can load GraalVM into an already running process using
JNI and access objects that way. JNI isn't a great API by any means but it
works and there are tools to bind to it. It isn't new and I don't think
GraalVM without Substrate or Sulong innovates in this area.

So if you wanted to run JavaScript using GraalJS, from C, you would link
against libjvm, use JNI to initialise the VM with Graal as the JIT compiler
(there's a special flag for this), and then use the Polyglot API via JNI.

To bind from JavaScript to Polyglot _without_ having Graal be the host would
presumably require you to write a V8 extension that then loads the JVM using
JNI and proxies back and forth. I think there are projects that do this
already. But you wouldn't get the performance or convenience improvements than
Graal/Truffle are pioneering.

In the end though, embedding the JVM this way - at least for node apps - would
not be better or more efficient than using their node implementation, but
ignoring things like performance and debuggability the results are presumably
identical unless your code depends on an implementation detail of V8. So I
don't get why you'd do that.

------
ChickeNES
I wouldn't touch this with a ten-foot-pole without an explicit patent grant.
Oracle has misbehaved too much in the past (and present) to ever be trusted
again by the open source community in my opinion.

~~~
jake_the_third
This was the first thought that crossed my mind.

If I have a choice between running our stack 50 times slower (and thereby 50
times the cost) or running anything Oracle, I know which choice is cheaper and
doesn't come with an existential threat to my company.

Only governments and big corp are rich and reckless enough to take on this
kind of risk willingly.

~~~
carterehsmith
>> existential threat to my company

There is like a bajillion people out there running Oracle Java, MySql,
Virtualbox and so on. All of them Oracle products, and with permissive
licenses. Where is this "existential treat" thing coming from?

~~~
jake_the_third
>There is like a bajillion people out there running Oracle Java, MySql,
Virtualbox and so on. All of them Oracle products, and with permissive
licenses. Where is this "existential treat" thing coming from?

Oracle. (see, I can be sarcastic too)

Ignoring the fact that most of those users were likely acquired back when
those products were still known as Sun Java, Sun MySql, and Sun Virtualbox,
those "bajillion" people are not lucrative enough to warrant the effort. The
moment one of those people becomes large enough, Oracle's lawyers will come
knocking. If you're large enough, they will even go as far as to change how
copyright law itself is interpreted to get their fill.

With a company like that, entering any form of contract or agreement is a
major liability and an existential threat.

~~~
carterehsmith
"The moment one of those people becomes large enough, Oracle's lawyers will
come knocking."

Can we see an example of big Java user being called by Oracle's lawyers?
Excluding Google, they created their own Java with no regards to license, so
yeah they got sued. So... did anyone that just downloaded Java and used it,
got sued? I do not see it. Nor do I see what they could possibly be sued for.

~~~
profalseidol
How about this? [https://www.techrepublic.com/article/why-its-finally-time-
to...](https://www.techrepublic.com/article/why-its-finally-time-to-give-up-
on-the-name-javascript/)

------
RandomBK
Is there public documentation for the differences between the CE and EE
editions? The website mentions that EE "provides improved performance and
security for production deployments". What types of performance and security
optimizations are locked behind the EE edition? What is your criteria for
determining whether a new optimization belongs in CE or EE?

I also want to echo others' concerns about the license, lock-in, and lack of
explicit patent grant. It's a shame that Oracle's (well-deserved) reputation
is tainting so many excellent engineering efforts. I hope that these comments
serve as some form of feedback about the very real cost the Oracle brand has
suffered as a result of its legal activities.

------
chrisaycock
Truffle makes it possible to implement a JITed dynamically-typed language
simply by annotating actions on the AST.

[http://www.graalvm.org/docs/graalvm-as-a-
platform/implement-...](http://www.graalvm.org/docs/graalvm-as-a-
platform/implement-language/)

Here's an example of the addition operator from Graal's SimpleLanguage:

    
    
      @NodeInfo(shortName = "+")
      public abstract class SLAddNode extends SLBinaryNode {
    
          @Specialization(rewriteOn = ArithmeticException.class)
          protected long add(long left, long right) {
              return Math.addExact(left, right);
          }
    
          @Specialization
          @TruffleBoundary
          protected SLBigNumber add(SLBigNumber left, SLBigNumber right) {
              return new SLBigNumber(left.getValue().add(right.getValue()));
          }
    
          @Specialization(guards = "isString(left, right)")
          @TruffleBoundary
          protected String add(Object left, Object right) {
              return left.toString() + right.toString();
          }
    
          protected boolean isString(Object a, Object b) {
              return a instanceof String || b instanceof String;
          }
      }
    

[https://github.com/graalvm/simplelanguage](https://github.com/graalvm/simplelanguage)

By default it uses an arbitrary precision adder. But node rewriting on the AST
(predicated by the "guard") provides specializations for _long_ and _String_
types. The long-type execution is a "fast path" that executes machine
instructions directly; the String-type execution is a string concatenation.

A research paper provides further details:

[https://dl.acm.org/citation.cfm?id=2658776](https://dl.acm.org/citation.cfm?id=2658776)

The full tutorial is at:

[https://github.com/oracle/graal/blob/master/truffle/docs/Lan...](https://github.com/oracle/graal/blob/master/truffle/docs/LanguageTutorial.md)

~~~
chc4
Someone I know wrote a Java implementation of the small VM for an open source
project that had a simple C interpreter. My first thought was "wait, why?",
until they mentioned that it was more than 10x faster and much, much easier to
write and extend. You basically get a very good JIT engine for free. Not gonna
underestimate Truffle after that.

~~~
grashalm
Which one was it? Can you remember? One of these?

[https://github.com/oracle/graal/blob/master/truffle/docs/Lan...](https://github.com/oracle/graal/blob/master/truffle/docs/Languages.md)

If not. Please let me know.

~~~
chc4
It's not listed there, and didn't reach full feature parity (and seems to be
dead now).

[https://github.com/frodwith/jaque](https://github.com/frodwith/jaque) is the
project though, which is an implementation of the Nock VM from Urbit

~~~
grashalm
Ho wow, never heard of it. Will put it on the experiments list. Thanks a lot!

~~~
frodwith
Hi, author of jaque here. I've been working on some other things for a little
while, but I'll be getting back to jaque soon. It's quite out of date and
needs to be brought up to 1.0 and cleaned up a bit before I start grousing
about the stack issues I was running into on the mailing list, but when I last
was working on it I was running into issues with Graal when trying to increase
the java stack size. Deep but bounded head recursion is quite common in nock,
and I seem to recall I needed about 8 megs of stack space (I just passed -Xss
8m or something on the command line) and Graal slowed waaaay down. That's
where I left it.

~~~
grashalm
Truffle tech lead here. Happy to hear you are not giving up :-) Do you mind if
I include your language on the experiments list?

BTW.: I'd recommend upgrading one Truffle release at a time. So it should
always continue to compile. Just fix the deprecation warnings and continue
with the next version until you reached the last version. We always keep
deprecations for at least one version before we remove/break APIs.

If you want to discuss something in more detail feel free to join us in the
Gitter chat: [https://gitter.im/graalvm/graal-
core](https://gitter.im/graalvm/graal-core)

We don't bite.

~~~
frodwith
> Do you mind if I include your language on the experiments list?

Not at all! Thanks for the advice, and I'll take you up on the invitation to
come chat before too long.

------
maltalex
Can someone please explain this?

> Are you working on a Java application? Do you want a faster runtime? Enhance
> your code with JavaScript!

First, the JVM already has the Nashorn JS engine. Second, if I'm "working on a
Java app", that means that it's already running in a JVM. Where does the
faster runtime come from? Is executing JS from Java using Graal faster than
running actual Java code? Is it just faster than Nashorn? Something else?

~~~
grashalm
The Graal compiler is compiling Java code to faster machine code on top of the
JVM. Also GraalVM's JavaScript implementation uses an entirely different
approach by using Truffle for its implementation making it significantly
faster. Also GraalVM ships with Node.js support, tooling and other languages.

Here is a full list of reasons: [http://www.graalvm.org/docs/why-
graal/](http://www.graalvm.org/docs/why-graal/)

Here are some (maybe a bit outdated, but independent) benchmarks comparing it
to Nashorn:
[http://blog.nidi.guru/tech/javascript/2018/04/02/javascript-...](http://blog.nidi.guru/tech/javascript/2018/04/02/javascript-
benchmarks/)

We have some way to go to beat V8.

~~~
thinkloop
From the provided link:

\- graal has superior compiler technology based off of a research paper [1]
that:

\-- has superior ability to remove costly object allocations in many scenarios

\-- has better inlining and more aggressive speculative optimizations

\-- has smarter jit compilation

[1] [http://www.ssw.uni-
linz.ac.at/Research/Papers/Stadler14/Stad...](http://www.ssw.uni-
linz.ac.at/Research/Papers/Stadler14/Stadler2014-CGO-PEA.pdf) (pdf)

~~~
alexprokopec
A few additional papers with details on Graal IR and optimizations:

[http://lafo.ssw.uni-
linz.ac.at/papers/2013_VMIL_GraalIR.pdf](http://lafo.ssw.uni-
linz.ac.at/papers/2013_VMIL_GraalIR.pdf)

[https://dl.acm.org/citation.cfm?doid=2245276.2232084](https://dl.acm.org/citation.cfm?doid=2245276.2232084)

[http://aleksandar-prokopec.com/resources/docs/graal-
collecti...](http://aleksandar-prokopec.com/resources/docs/graal-
collections.pdf)

------
_wmd
Might this (today, tomorrow) become another way to get access to the wonderful
Lucene from non-Java environments? A long, long time ago there was a GCJ-based
solution, but it was never loved much (either the port or GCJ itself).
SubstrateVM looks potentially delicious here

edit: lol: talk about a low blow!

> The community version does not support DWARF information. The enterprise
> version supports all native tools that rely on DWARF information, like
> debuggers (gdb) and profilers (VTune).

~~~
mike_hearn
Well, there has always been JNI. If you want to access Lucene from C or
runtimes that can call into C then you could do that for years.

Otherwise with GraalVM you could run your non-Java environments on Graal and
go at it the other way around.

------
claytongulick
This project is remarkable! Really excited to see where it goes. The biggest
problem I see so far is sparse docs on interop. I see docs with a trivial
example of importing simple types from java and using them in node, which is
amazing! However, this is pretty far from a real world example. In the real
world there are deep type graphs and dependencies and functions that look like
IWidgetInterface createWidget(IAbstractWidgetFactory<CoolWidget> factory)
etc... seeing examples of dealing with complex types, anonymous Callables,
generics, etc... would be great.

~~~
grashalm
Thanks for the feedback. We will definitely improve the polyglot docs in the
next weeks. There is lots more to show.

Are you calling from Java? Then there are more examples here:
[http://www.graalvm.org/docs/graalvm-as-a-
platform/embed/](http://www.graalvm.org/docs/graalvm-as-a-platform/embed/)

Also some of the examples on the website use interop:
[http://www.graalvm.org/docs/examples/](http://www.graalvm.org/docs/examples/)

------
viach
GraalVM

1\. Community Edition (CE)

> GraalVM CE is available for free for development and production use. It is
> built from the GraalVM sources available on GitHub

2\. Enterprise Edition (EE)

> GraalVM EE provides additional performance, security, and scalability
> relevant for running critical applications in production. It is free for
> evaluation uses and available for download from the Oracle Technology
> Network.

"performance, security, and scalability" words don't present in p1. Is it just
me or...?

------
royjacobs
This is wonderful. I'm looking forward to playing around with JavaFX. Being
able to compile that to a native image is huge! It would effectively
invalidate the Electron approach of building "native" applications.

~~~
pjmlp
That approach was already invalidated long time ago.

All major commercial JDKs do support AOT compilation and ExcelsiorJET is free
for open source projects.

~~~
royjacobs
This is _completely_ free, though.

------
ksec
One VM to Rule them All.
[https://news.ycombinator.com/item?id=6358772](https://news.ycombinator.com/item?id=6358772)

[https://news.ycombinator.com/item?id=6232240](https://news.ycombinator.com/item?id=6232240)

That was the earliest post I remember from HN. But I record there some other
information scattered around a little before that.

So this is nearly 5 years coming. I am amazed what at first seems like
fantasy, impossible work is now actually thing. 2012 / 2013 was the year when
VM and JIT has lots of innovation. Rubinus, LuaJIT, SpiderMonkey and all those
Javascript VM.

------
mc13
Great! Benchmarks of TruffleRuby vs JRuby vs Ruby looks very promising. edit:
[https://pragtob.wordpress.com/2017/01/24/benchmarking-a-
go-a...](https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-ai-in-
ruby-cruby-vs-rubinius-vs-jruby-vs-truffle-a-year-later/)

~~~
aardvark179
If we can successfully JIT it we normally do very well. The caveat is that we
do have warm up time and if we can’t compile stuff then you won’t see the same
level of performance.

------
ksec
I know lots of people are worry about Oracle. But the license is extremely
clear, it is the same as Java.

So like the JVM or JDK, there is nothing stopping you from for forking the
code, as long as you don't call it Java, and "your" JVM would not get the test
suit.

GPL 2 with Classpath exception has been with us for so long. I know you hate
Oracle, but I don't see any downside to it. I mean half of the Internet
literally runs on JVM and MySQL.

I had to look hard and it doesn't seems to have any strings attached.

------
ihnorton
> With the SubstrateVM it is possible to produce a single, statically linked
> native binary executable version of Graal.js, which doesn't need any JVM to
> run.

How large is the resulting executable? There was some mention of shares
libraries — is it possible to build a runtime that is callable from C?

Relatedly, does the GraalVM _java_ executable support JNI?

I’m also curious about the runtime footprint in general; any idea what is the
smallest possible VM for a real but relatively-small language like Lua?

~~~
chrisseaton
> How large is the resulting executable?

A minimal executable is about 5 MB.

> There was some mention of shares libraries — is it possible to build a
> runtime that is callable from C?

Yes you can compile a JAR to a shared library with C function entry points.

> Relatedly, does the GraalVM java executable support JNI?

Yes.

> I’m also curious about the runtime footprint in general; any idea what is
> the smallest possible VM for a real but relatively-small language like Lua?

Real language VMs are quite a bit bigger - a hundred MB or so.

~~~
pritambaral
>> I’m also curious about the runtime footprint in general; any idea what is
the smallest possible VM for a real but relatively-small language like Lua?

> Real language VMs are quite a bit bigger - a hundred MB or so.

Don't know if you're trying to say Lua is not a real language, or just skipped
the part about Lua.

~~~
chrisseaton
No, hello-world executables _built using SVM_ are 5 MB or so. Real world
language VMs _built using SVM_ are a hundred MB or so. If you had a language
VM for the real world language that is Lua _built using SVM_ it would probably
be a hundred MB or so.

I'm not passing any opinions about any languages or VMs here.

~~~
ihnorton
> If you had a language VM for the real world language that is Lua built using
> SVM it would probably be a hundred MB or so.

Is this mostly JRE? Would Jigsaw help, or is SubstrateVM already doing
something like that? (To be clear, this tech is really impressive! Just trying
to get a sense of embeddability constraints)

~~~
chrisseaton
The SubstrateVM already does whole-world analysis to only compile methods that
are actually used, so reducing the methods in the JAR before hand (which is
what Jigsaw) would do, would not change anything.

Language VMs compiled using SubstrateVM are larger than you may think because
as well as the native code they also need to contain a representation of the
code that the compiler can read (IR) so it can dynamically compile the methods
that are combined to form the compiled version of your user's code, and we
also need to compile a sort of runtime debug information that allows us to
jump from optimised code back to the native code when an optimisation proves
to be wrong. This is a novel thing - most language VMs jump from optimised
code to a bytecode interpreter - we have to jump back to the native code as
there is no bytecode interpreter. Finally, a language VM also needs to include
all of the Graal compiler itself for dynamic compilation, which is quite a bit
of code.

------
oneplane
Keep in mind that while this is nice technology, it's Oracle-based, split in
CE/EE (which in itself is not a problem, but CE doesn't run on macOS), and
they will find a way to screw you over at some point in the future regardless
of what you do, use or choose.

~~~
jokr004
Oh come on, I'm no fan of Oracle but this is some FUD nonesense..

~~~
thiagocsf
I think it’s a legitimate licensing concern.

I’m surprised you called it FUD, given the high-profile case against Android
(google).

I was about to recommend we try it at my company and gave up as soon as I read
“Oracle” in the company name.

Call it FUD if you want but Oracle does have a damaged reputation.

~~~
pjmlp
It happens when companies don't behave as they should, and others lack the
money to enforce how things should be.

"James Gosling: Oracle vs Google"

[https://www.youtube.com/watch?v=JQ7xVO9lqD0](https://www.youtube.com/watch?v=JQ7xVO9lqD0)

~~~
madmulita
I don't understand the point of the clip. He says that the code was similar to
Sun's, but clearly admits that, not being involved with the trial, he didn't
get to see Google's code.

------
kristianp
Runs a small erb template more than 50 times faster than jruby [1]. No mention
of rails on that page though. It can also run C extensions.

[1]: [http://www.graalvm.org/docs/reference-
manual/languages/ruby/](http://www.graalvm.org/docs/reference-
manual/languages/ruby/)

------
zackbloom
How is this better than compiling everything to WebAssembly and using V8 as
your interpreter?

~~~
kllrnohj
Because WebAssembly is extremely limited? Unless you need to ship on the web,
using WebAssembly is almost certainly a bad decision as it makes highly
compromising tradeoffs that you don't need.

~~~
abc_lisper
Didn't know about this. Can you point me to some references that list the
tradeoffs?

~~~
scriptproof
WebAssembly is a tool in work, supported by Google, Microsoft, Apple, etc...
Currently it lacks a garbage collector, but this is planned. I would bet on
wasm to be the holly graal in the future, more than anything else.

------
pronoiac
I recently stumbled on an announcement for Graal and Truffle in my bookmarks:

[https://blog.plan99.net/graal-
truffle-134d8f28fb69](https://blog.plan99.net/graal-truffle-134d8f28fb69)

discussed at
[https://news.ycombinator.com/item?id=13343845](https://news.ycombinator.com/item?id=13343845)

The idea there: "Graal is a research compiler. ... Truffle is a framework for
implementing languages using nothing more than a simple abstract syntax tree
interpreter."

As a bonus, you get high speed, good instrumentation for debugging and
profiling, with great garbage collection, and hotswap code as you develop.

------
shthed
So to contribute to this you have to sign the Oracle Contributors Agreement:
[http://www.oracle.com/technetwork/community/oca-486395.html](http://www.oracle.com/technetwork/community/oca-486395.html)

"The OCA gives Oracle and the contributor joint copyright interests in thre
code."

What does 'thre' mean? ;P

They want it physically printed and signed.. sigh, I haven't printed anything
in years.

Is this normal to require a scanned signature for CLAs? I noticed Apache CLA
is the same (they want scanned paper signature), but all others I've seen are
an online form.

------
Steltek
Am I correct in reading the license in Github that this is all GPL? Albeit
GPL2 but still not some Oracle proprietary license.

"One VM to rule them all" reminds me of Parrot VM (for Perl 6). Looks like
development slowed down a year or two ago. Back then, it got me excited as it
looked like the "open source community" alternative to "Big Corporate Java".

[https://en.wikipedia.org/wiki/Parrot_virtual_machine](https://en.wikipedia.org/wiki/Parrot_virtual_machine)

~~~
seiferteric
I was very interested in Parrot VM for a while too for the same reasons. I
always liked the idea of language interoperability and being able to use the
best libraries of each language. This brings me to a question I have had for a
while, why do we even have so many language specific libraries for common
tasks instead of more "universal" libraries with bindings for each. Of course
these exist, but I feel like this should be almost the default, and language
libraries would just be wrappers to help it integrate better with the language
(like making it more pythonic for python etc). That way you would have at most
a few competing libraries for each task with higher quality. Also it would be
easier to bootstrap new programming languages since that is a big initial
barrier (having few libraries).

~~~
jerf
There are fundamental semantic differences between the languages. An immutable
language will always have a serious impedance mismatch with a mutable library.
A library that uses GC won't work in a language without them, a specific
example of the general principle that memory management strategies vary
widely. A library that uses dynamic types will have a huge conversion boundary
with a statically-typed language, and vice versa. A library that uses threads,
or expects threads, will have a hard time working in an event-based
environment that depends on code voluntarily yielding to maintain its
responsiveness. A language that wants to provide guarantees about correctness
or whathaveyou is forced to give all those up to talk to a lowest-common-
denominator library.

And that's just the top-level differences. It gets worse as you get into the
details of API style and the costs of the indirection layers to convert into
the local style, assuming conversion is even technically possible.

Even if you write with the lowest possible common denominator of C or Rust
with no runtime, you'll _still_ encounter a significant subset of those
issues. And of course we still will use such things; all serious languages can
communicate in some manner with a C implementation of a library. (Not for any
theoretical reasons, really, C has more opinions than people often realize,
but because it's still the baseline current systems are built on.) But it
can't be as good as a native implementation.

~~~
dboreham
>you'll still encounter a significant subset of those issues

Heck you will encounter those issues in a large project using only one
language!

------
polskibus
To what extent is this compatible with all existing libraries for allegedly
supported languages?

I'm also curious if .net standard/c# support is being planned.

~~~
grashalm
You can check libraries here: [http://www.graalvm.org/docs/reference-
manual/compatibility/](http://www.graalvm.org/docs/reference-
manual/compatibility/)

We don't test all of them but many.

We have considered .NET support but we are not actively working on it right
now. But GraalVM is an open platform. Everyone can develop a language for it:
[http://www.graalvm.org/docs/graalvm-as-a-
platform/](http://www.graalvm.org/docs/graalvm-as-a-platform/)

~~~
bitmapbrother
It would be hilarious to discover if C# runs better on the JVM then CLR.

------
rajangdavis
Going to try it out, but does anyone know offhand whether GraalVM can be ran
within the Linux subsystem in Windows 10?

~~~
grashalm
If you can run a HotSpot JVM there then also GraalVM should work. I don't
think we tested that.

~~~
rajangdavis
Will let you know what I find out, thanks!

Edit: It works (for Ruby and Python)

Here is how to set up GraalVM for the Linux Subsystem on Windows 10:

1\. Enable and Install Ubuntu for Windows 10: [https://docs.microsoft.com/en-
us/windows/wsl/install-win10](https://docs.microsoft.com/en-
us/windows/wsl/install-win10)

2\. Download the EE edition of GraalVM to Windows:
[http://www.graalvm.org/downloads/](http://www.graalvm.org/downloads/)

3\. Mount the folder that has the tar file:
[https://stackoverflow.com/a/42586455/2548452](https://stackoverflow.com/a/42586455/2548452)

4\. Unzip the files (tar xvfs graalvm-ee-1.0.0-rc1-linux-amd64.tar.gz)

5\. Create a .bash_profile for setting the $PATH (my personal preference)

6\. Follow the instructions from the following up until the "Running
Programs": [http://www.graalvm.org/docs/getting-
started/](http://www.graalvm.org/docs/getting-started/)

7\. Follow instructions for installing LLVM and locales:
[https://github.com/oracle/truffleruby#system-
compatibility](https://github.com/oracle/truffleruby#system-compatibility)

8\. Follow instructions for installing libssl-dev:
[https://github.com/oracle/truffleruby/blob/master/doc/user/i...](https://github.com/oracle/truffleruby/blob/master/doc/user/installing-
libssl.md)

9\. NOW continue on with everything _after_ "Running Programs":
[http://www.graalvm.org/docs/getting-
started/](http://www.graalvm.org/docs/getting-started/)

Getting npm to work:

I could run node -v, but could not run npm and I was getting this error:

jvm library could not be loaded:
/home/raj/graalvm/jre/lib/polyglot/libpolyglot.so: cannot enable executable
stack as shared object requires: Invalid argument

I fixed it by running the following:

1\. sudo apt-get install prelink

2\. sudo execstack -c ~/graalvm/jre/lib/polyglot/libpolyglot.so

Going to do some experimenting, but so far so good!

------
SureshG
Really excited to see 1.0 release. Have been following Graal and SubtrateVM as
a way to create native binaries (specifically CLI tools).

So, any plans to support Windows and MacOSx for CE?

Also, any support for cross-compilation to generate native-binary for a
different target(something like Golang GOOS) ?

------
psandersen
This looks really interesting.

Can anyone comment on how mature the R and python support is? I'm coming at
this from an ML/data science background, so anything that speeds up the above
while maintaining broad library support would be a great help.

~~~
grashalm
\- FastR is around for several years. Language support is pretty much done.
Its mostly about getting to run CRAN packages that use native extensions.

\- Graal.python is pretty new and its really early days. So even basic
language things might break right now. But we are investing a lot of resources
in Python support.

You can check for compatibility of packages here (not yet for Python):
[http://graal-staging.us.oracle.com/docs/reference-
manual/com...](http://graal-staging.us.oracle.com/docs/reference-
manual/compatibility/)

~~~
psandersen
Thanks for that, link seems down unfortunately. I use data.table a lot but
would happily switch if the dplyr family of packages work.

Would love to use this in Rstudio for exploratory analysis which would also
need ggplot to work. Quite often have to cancel long running tasks when
exploring a data set, so even if its a bit slower for interactive tasks but
much faster for longer running tasks would be huge. E.g. typical interactive
finished in 1 second instead of 50ms, but large loops that would take an hour
finish in 10 minutes.

~~~
grashalm01
You will like to hear that there is some rstudio integration in the works.

Here is the correct link: [http://www.graalvm.org/docs/reference-
manual/compatibility/](http://www.graalvm.org/docs/reference-
manual/compatibility/)

(Accidentally posted the internal link :D)

~~~
psandersen
Awesome, thanks for that. I'll definitely give it a shot once rstudio is
supported.

------
ksec
Some benchmarks I saw on Twitter.

[https://gist.github.com/havenwood/6fed7dd17131330ae4fd36a06f...](https://gist.github.com/havenwood/6fed7dd17131330ae4fd36a06fd2c19b)

*( Scroll to the bottom for Summary )

------
ajpalkovic
On the "why graal" page, it says that one benefit is you can use a larger heap
size for nodejs applications. I would imagine one other big benefit is that
you can have true multithreading since the app now runs on the jvm. Is this
indeed possible? Is there any guidance on how to do it? Rhino had the concepts
of Scope's and Context's to somewhat safely parallelize code, so curious if
there are similar primitives in Graal?

~~~
dboreham
>I would imagine one other big benefit is that you can have true
multithreading

Thank The Maker.

------
jahlqvis
Does this mean I can convert my C++ win32 desktop app to run on virtually all
platforms?

~~~
earenndil
Probably not. Win32 itself is a windows-only API -- although wine is a thing.

------
PedroBatista
Does GraalVM truly supports hotreload/class reloading without any hacks
(Agent, new classloader every reload) unlike Hotspot?

Until then, areas like web development always will be a torture.

------
iLemming
I wonder what this means for Clojure and Clojurescript developers

~~~
didibus
For Clojure, I think it means native compilation, with fast startup times, and
the ability to interop with Python, Ruby, or any of the other Graal languages.
Not sure there would be an advantage to re-implementing a Clojure on Graal.
Clojure is not an interpreted language like Ruby, JavaScript and Python is, so
I don't think Graal adds as much benefit here.

For ClojureScript, it would mean full circle. You could run your ClojureScript
back on the JVM, and have Java interop from it.

------
claudiug
there is any roadmap to make available for MacOS?

~~~
grashalm
GraalVM EE has a MacOS version that is free for evaluation uses.
[http://www.graalvm.org/downloads/](http://www.graalvm.org/downloads/)

There are technical reasons we cannot have a CE for Mac OS as well. But we are
working on that.

~~~
claudiug
[https://github.com/oracle/truffleruby/releases/tag/vm-1.0.0-...](https://github.com/oracle/truffleruby/releases/tag/vm-1.0.0-rc1)
this will contain EE or CE version?

~~~
grashalm
Neither. You download EE or CE from graalvm.org. Then you install using the
component installer.

gu -c install org.graalvm.ruby

or from a local file

gu install ruby-installable-linux-amd64.jar

------
youdontknowtho
That is super interesting. Im particularly interested in C++ with the other
languages mentioned.

------
wemdyjreichert
Does it support lisp? If not, any plans to add soon?

------
ksec
Is SubstrateVM part of this release ?

~~~
grashalm
Yes. Its behind the native-image command.
[http://www.graalvm.org/docs/getting-started/#native-
images](http://www.graalvm.org/docs/getting-started/#native-images)

------
holydude
This is seriously huge. I wonder if it actually gets popular.

Can anyone comment on TruffleRuby ? What remains to be done for it to be
production ready ? GraalVM page still mentions it's experimental.

~~~
aardvark179
We are getting there, lots of things work right out of the box just fine. C
extensions are still being actively worked on as they often need some amount
of patching because of assumptions they make about types and so forth. I think
we can reduce that, but I doubt it can will disappear entirely, but in the end
I hope extension authors will test on TruffleRuby themselves and patch the
code themselves.

~~~
holydude
I know that you are using Rails as a reference point so is there any ETA when
will be most of the features usable ? (openssl,activerecord,nokogiri..etc) ?

~~~
aardvark179
OpenSSL and nokogiri already work pretty well. ActiveRecord works providing
you have a database driver and I’ve got a rough set of patches for pg that I’m
working on right now.

I’m working on Discourse at the moment and can run the dB create and migrate
tasks and I’m working on the asset compilation pipeline, but it’s all pretty
rough and won’t be our final solution.

~~~
ksec
Just wondering if any Discourse or Rails Core people involved to get it
working?

~~~
aardvark179
Not at the moment. I'm mostly doing some ugly hacks to get stuff working and
generating a list of bugs for things we need to fix properly. Looking at my
branch I think there's one small change that we will want to do PR for in the
end, and some dependencies that we may want to make platform dependent (though
they recently did change a couple for JRuby, which also helps us). Pretty much
everything else I hope to back out when we've fixed a few of the root causes.

------
dang
We changed the URL from the announcement post at
[https://blogs.oracle.com/developers/announcing-
graalvm](https://blogs.oracle.com/developers/announcing-graalvm). Pretty sure
the project page will be better for HN.

~~~
nirvdrum
I was uncertain which to use and went with the site announcing what was new,
even if a bit corporate. I guess I picked wrong. Thanks for fixing.

------
bitmapbrother
This is an epic announcement and it further extends the JVM as the best VM to
develop new languages for and port existing ones to. I'm curious though, is
there a Truffle version of the Java language that the Graal JIT uses?

~~~
grashalm01
Not yet. It's on our roadmap.

